BRL-CAD GSoC project

GSoC project report:

This page contains a report on my GSoC project “Implementation of a g-k converter and Improvements to the existing k-g converter” with a summary of the project and its outcomes.

Project summary:

The project’s goal is to create a file converter from LS-DYNA .k files to BRL-CAD .g files from now on we will call it (k-g) converter, and vice versa. LS-DYNA is an advanced general-purpose multiphysics simulation software package and BRL-CAD is a constructive solid geometry (CSG) solid modeling computer-aided design (CAD) system. The benefits of creating this converter are clear from both sides, where converting a .k file to a BRL-CAD database allows the user to benefit from the vast capabilities of BRL-CAD, like modifying the geometry and performing a render using the advanced Raytracing capabilities of BRL-CAD. On the other hand, converting a model from BRL-CAD to LS-DYNA allows the users to run a physical/ structural analysis using geometry, for which they invested a non-trivial amount of time creating in BRL-CAD. A preliminary implementation of the (k-g) converter was created by the BRL-CAD community <deve_k-g and my contribution was concentrated on the implementation of additional features to the existing converter. Here I will present a list of outcomes.

Bugs:

Empty Database Error:

In the old (k-g) converter there was an issue with converting a .k file related to ifstream::tellg() returning a wrong position in the ASCII file. The solution was to open the input file (.k) as a binary file. The pull request for this bug fix is provided in this link <patch.

LS-DYNA Part Made out only of Triangles:

An old piece of code was left in the new k-g converter. in this code when the converter encounters a triangle, it tries to go back to the privous part. This code was erroneous considering that an LS-DYNA part can contain shell elements which could be quadrilaterals, triangles or any other available type of shell elements. Another issue was that if the converter is in the first part and it tries to go back to the privous part it will find nothing and it will attempt to read a piece of memory that is not allocated. The fix is provided in the following link <update k-g.cpp

Developments:

Handling LS-DYNA command *PART_ADAPTIVE_FAILURE:

In LS-DYNA a model is divided into parts, these parts contain information about finite elements and their properties. The LS-DYNA part is connected to a certain mesh, and this mesh can be changed during the analysis. This feature is implemented in LS-DYNA through the command *PART_ADAPTIVE_FAILUR. Considering the importance of this information related to the adaptive meshing of a part at a certain point in time. we have implemented this command as an attribute for the region where the part exists. This implementation is of interest in case one wants to convert the .g file back to a .k file and it allows the preservation of this important information. The pull request related to this development can be found in the following link <PART_ADAPTIVE_FAILURE. The following image shows how one can check for such attributes using MGED Attributes in a region

Reading Format:

There are multiple formats for a .k file, the first issue was encountered reading node coordinates in a .k file. The initial assumption was to consider space-separated values. This was a wrong assumption considering that a .k file has three types of format fixed format (comma separated), free format ( known number of characters for each field) which includes standard and long formats, and I10 format. an implementation of the node standard format can be found in the following link <node standard format. the comma separated format, and the I10 format implementation can be found in the follwoing link <formats. The format of a .k file can be set at the beginning of the file after the command *KEYWORD for example if a file has the long format one will find one of the following commands (*KEYWORD LONG=K) (*KEYWORD LONG=Y) (*KEYWORD LONG=S), while in case of I10 format the command is (*KEYWORD I10 LONG=S), nonetheless a node format can be specified later on in a file. In case the node format is I10 the *NODE keyword will be followed by the symbol (%) i.e (*NODE %), while the command(*NODE +) indicates the long format, and (*NODE -) indicates the standard format. Additionally, this pull request handles the long format adapted in old .k files, where a node with a Long format is spread on two lines.

Case-insensitive keywords

The keywords in the .k file are case insensitive, hence we have included a code to handle this case. the code can be found in the following link <insensitve. later on, it was noted by my supervisor that this situation could be handled in a simpler way <oneLine

Solid Elements and Geometry Class:

The elementary implementation of the k-g converter was able to handle shell elements. I have worked on developing the Solid element. Initially, the elements had to be read from the .k file then the information should be stored in an intermediate data structure, for which I have developed the Arbs class. This pull request was adapted to handle different kinds of solid elements, the traditional Hex8 element was implemented as arb8 on the BRL-CAD side. other elements are handled with arb7 for 7 nodes solid element, arb6 for six nodes solid element, arb5 for 5 nodes solid element, and arb4 is still under development. Additionally, the Geometry class was developed to include the Bot class and the Arbs class. This development allowed the conversion of any model that contains solid elements. as shown in the following image Solid elements converted from .k file to BRL-CAD database

Random coloring of the parts:

Considering that each part in a .k file is represented as a region in a .g file. If all the regions had the same color the resulting converted model is hard to see clearly. To avoid this issue random coloring was implemented for each region. In the following images, one can see the difference between a model with only one color and a model after the implementation of the random coloring. The code can be found in <coloring

Car model with one color

s Car model with random coloring

Systematic Implementation of Commands and Options:

Considering the huge amount of commands and their corresponding options in LS-DYNA, an approach that relies on converting example .k files and fixing the error is bound to be inefficient, hence I have started to implement all available commands and their corresponding options in a systematic way relying on LS-DYNA documentations. The following pull request <commands and options has been opened to handle the following issues:

Implementation of the Resultant beam:

A beam in LS-DYNA can have diffrent kinds of cross section, in order to represent these kinds of beams in the .g database, I am working on developping the sketch and extrude classes. The code related to this development can be found in the follwoing link <sketch. The goal is to implement beam elements with the following types of cross-sections:

The beam with SECTION_01: I - Shape is under development. The following image shows the sketch of the cross-section in .g database

SECTION_01 : I - Shape

TO DO:

The project is not finished by any means there is still a substantial amount of work to do. Here is a preliminary to-do list:

Useful information: