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.

  • Sven says:

    Hi Suri,

    This is a very promising post. As you know, I’m extremely interested in this kind of model development. For the models that I work with, this level of management takes up far too much time when preparing a model for use in a ‘new’ situation.

    This basically means that a model should be developed with consideration for its use. In particular, I think the best models are those that can be placed in a new simulation without prior knowledge of the inner workings (element/id numbers etc) of that model.

    Imagine a dummy model produced that came with a small ‘how to use’ pamphlet, showing pictures for a series of body regions and the corresponding entity set (or box) ID. The user of this model could then place it in a new simulation by referencing this pamphlet for all of the boundary conditions (contacts/loads etc), all without needing to open the model and look at its details.

    One main obstacle at the moment for this type of user, is that they are likely to want to use a GUI to place the model or view the regions (if the pamphlet above is still being printed πŸ˜‰ . I use two main pre-processors: Hypermesh and LS-PrePost. Unfortunately, both of these fail to properly read the *INCLUDE_TRANSFORM cards (particularly when unit transformations are involved). I know this is a supporting software problem, but it’s still an obstacle to easy subsystem swapping.
    Another is also a software problem : the set__general cards. I’m actually not sure about PrePost, but I know that previous versions of Hypermesh did not show any set_general sets when visualising contact pairs. Therefore I have changed my habits and avoided using _general sets at all. When the supporting softwares implement the full set of dyna cards, this problem can be avoided.

    When considering the case of using boxes to define sets, you can reference a box ID from a DEFINE_BOX card. Unfortunately, DEFINE_BOX takes coordinates in the global coordinate system. Therefore it is not reliable when dealing with subsystems or posture changes (imagine defining a box around a dummy’s wrist, then changing that dummy’s posture). The DEFINE_CONTACT_VOLUME can be placed in a specific coordinate system (such as the dummy’s arm coordinate system), however contact volumes are not as flexible as boxes when trying to combine them into sets.

    Another way to define sets more flexibly would be with some kind of set boolean operations. For example, you can currently add part sets using set_part_add, however I think it would be useful to extend this to other boolean operations such as minus, union, intersect.

    Being able to combine coordinate system-based boxes with other sets in boolean operations would be excellent.

    For example, a set such as:
    All shell elements that are inside BOX(5), and exist in SET_SHELL(3) but not in SET_SHELL(7).

    This has all been a bit random with just the few ideas that come immediately to mind, but I think development of standard ways to make models more user friendly will allow everyone to spend more time making them more advanced πŸ™‚


  • Sven says:

    Hi again Suri,

    First of all, it was great to see how quickly the last suggestion regarding the define_contact_volume inclusion in sets was added to Dyna!

    Now, just another quick suggestion that might facilitate the “share nothing” approach to using dyna. I just set up an occupant simulation using a single shoulder belt (included as a separate .k file of course). This seatbelt file has a couple of fancy things like seatbelt sliprings. I now want to see what happens if a second seatbelt is added (forming an ‘X’ across the occupant).

    I thought I’d be a bit sneaky and and just re-include my seatbelt file, scaling its X-coordinates by -1, effectively mirroring it. I was feeling pretty pleased about how easy this was, until I tried running it in dyna and came across an error. The problem is that each slipring requires a unique slipring id, so re-including it breaks this requirement.

    As part of the INCLUDE_TRANSFORM card, there are options to offset the ids of many properties (node ids, element ids etc), but slipring id isn’t one of them. I imagine that there are many other specialised dyna entities that require unique ids that prevent a model from being re-included easily. I’m not sure of the best way to fix this… perhaps another INCLUDE_TRANSFORM offset field that offsets all “other” ids.

    At the moment for my simulation I need to either copy/paste the seatbelt file and increase the slipring ids in one file appropriately (breaking the general “duplicate code as little as possible”), or extract the slipring definitions out of the seatbelt file and put them into the including file (breaking the “share nothing” approach).

    On a related note, I think that would be great value in moving away from having everything in Dyna referenced by ID, and moving towards allowing textual references. I know that this would be a *major* rework of a lot of underlying dyna code. However for extremely complicated models with many connecting parts/systems/subsystems, I think it would greatly assist the developer to let *dyna* manage a database of ids, rather than needing the developer to maintain their own database that links an id to a human-recognisable name.


  • Sven says:

    Please let me clear up that last post: LS-Dyna did *not* have a problem with seatbelt sliprings being multiply defined. LS-PrePost in fact gave me the warning when I loaded my file, and I just interpreted a separate dyna error (due to my own input error) as being due to the same cause.
    Oops πŸ™‚

Leave a Reply

Your email address will not be published. Required fields are marked *