In web technology, it is a common practice to build applications that “share nothing”. For example, if a web application is running on a web server, and you need move the application to another machine, it is extremely simple to do this if the app does not use data on the machine its running on. “Share nothing” principle promotes easy porting without the headache of migration its dependencies. Implementing such “share nothing” apps requires proper design and involves a good process developement.

In finite element simulations, we are usually involving in evaluating various “configurations” of our design. I am currently working on a barrier development project (details will come out shortly) where I have to evaluate the performance of the barrier in a variety of configurations and loading conditions. I wanted to do this such that there was no data duplication and efficiently. SET_NODE_GENERAL and SET_SEGMENT_GENERAL to the rescue.

If you look at features that help us “connect” components together, it is either by “nodes” or by “segments”. Parts/Shell are just a means of getting either of nodes or segments dependent on the type of connection. The best approach to provide a list of nodes and segment list is to reduce the amount of ID usage. This can be achieved by using a series of BOX defintions to achieve complicated shapes and the combination of which will gives us the desired node list that is independent of the model ids.

For connections involving contacts (TIED or Contact-Impact), we can use *DEFINE_CONTACT_VOLUME. I see so many cases where users use a dummy model and painstakingly have to define the contact between the dummy and the vehicle. And this needs to be done everytime the dummy is positioned in a new vehicle. This can be made easy by building a contact definition inside the dummy file that handles the interaction automatically using SET_NODE_GENERAL or SEG_SEGMENT_GENERAL and DEFINE_CONTACT_VOLUME such that it takes the appropriate segments without the user having to manually define them.

Based on this, if we start building subsystems (which are frequently swapped) that shares no IDs then it can be swapped or placed into any new environment using INCLUDE_TRANSFORM that helps us overcome ID, Position and Unit conflicts.

I am curious to know if this applies to your work. There will be obvious limitations of this approach and if you see any, please let us know. Perhaps we can use this to update LS-DYNA.