- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
I got an e-mail question a while back: “Does the ACIS Modeler work in Nano?”
After making sure that the sender was asking if ACIS can handle models at typical nanotechnology length scales, I sent back the following response:
Yes, you can choose “1.0” unit in ACIS to be whatever distance you want it to be. So a block of size “1.0” in a nano app could be defined to be 10 nanometers on a side.
This answer might seem pretty obvious, but every so often I get a similar question from a customer who’s confused about how units work in ACIS. And this confusion sometimes leads the customer to implement units in their application in a way that makes it much harder to deal with changing units between models.
The way to navigate through this confusion is to always remember the following tautology: a length or distance always has units of length. In other words, there’s no such thing as an edge of length “1.0” – it’s really an edge of length “1.0 model units”. These model units can then be converted into “interface units” (the units used in the user interface), which might, for example, be mm, cm, or inches. The right way to manage this conversion in your application is to have a variable for each model that holds the conversion factor “X interface units / 1 model unit” and apply it to queries of and inputs to the model, rather than by hard-wiring your application to a particular choice such as 1 model unit = 1mm.
Here’s a trick question that goes to the heart of this point: If I hand you two SAT files, one containing a cube of size 1.0 and the other containing a cube of size 10.0, are the cubes of the same size? The correct answer is “I don’t know – you didn’t give me enough information about the SAT files”. The reason is that “1.0” and “10.0” are lengths expressed in “model units”, which can be different from model to model. Every SAT file also contains a field that tells how many mm correspond to 1 model unit; if I had told you that this value was 10.0 in the first file and 1.0 in the second then the answer would have been “yes”, since both cubes would be 10mm on a side. If your application holds a similar variable for each model which converts between model units and interface units, then you can read both files in without any rescaling – the first model’s conversion factor will simply be 10 times as big as the second’s.
For example, considers applications A and B. Both of them use interface units of mm. Application A is written so that 1 modeler unit is always 1mm, while application B is written so that 1 modeler unit is X mm, where X is a variable that is associated with the model. This is a bit more work for application B, since every query that returns a length needs to be multiplied by X, every query that returns a volume needs an X^2, and so on, while construction inputs such as extrusion distances will need to be divided by the appropriate power of X. The advantage of application B shows up when reading the first SAT file. In application B, X is merely set to 10. In application A, however, the model needs to be rescaled by a factor of 10. This is important because, given a choice between rescaling a model or not rescaling a model, not rescaling the model is better. This is because rescaling transformations should ALWAYS be fixed (ACIS is VERY non-robust against unfixed BODY transforms), which means that the actual geometry of the model is rescaled, which in turn runs the risk of kicking some geometric corner case over the edge of stability of some algorithm.
Application B also has an advantage if the Product Managers decide to enhance the interface to allow, for example, interface units of mm, cm, m, and inches. This is trivial to code up in application B – only the code that sets X needs to be changed. In application A, however, the conversion factor work that was done upfront in B will need to be done, but it is likely that the conversion factors will be fixed to 1 modeler unit = 1 mm. Since figuring out which queries/inputs need what power of X is the hard part of coding up application B, it doesn’t make a lot of sense to hard-wire model units to a particular, physical value.
Note that even application B can’t avoid all rescalings of models. If you want to perform operations (such as a Boolean) between two bodies that are in different units, one of the two will have to be rescaled (or copied and rescaled).
So the message for today is “write your application so that the model units of each model can be adjusted independently and independent of interface units”. That’s not the whole story though – we still haven’t talked about resabs!!
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.
