Ali Haydar Dev log 2024

Development log k-g converter 2024

This page will contain a day to day development record of the k-g converter, Google summer of code 2024

Coding period

• May 27 setting up the enviroment, the configureation is failing on both windows and ubuntu will have to ask the mentors for help. The issue seems to be related to BRL-CAD/bext, I will follow the procedure described in https://brlcad.zulipchat.com/#narrow/stream/104062-brlcad/topic/build
• May 28 tried to build bext first and then run the Cmake on brlcad specifying the bext_output direectory. the bext didn't build. on windows I am running cmake on brlcad from visual studio powershell, and on ubuntu the building process seems to be working. Eventually using cmake from VS powershell is the way to go in windows. the build is successful on windows and ubuntu. I started working on the bugs in k-g converter.
• May 29 I found the peace of code that is causing the assertion error when trying to convert spr4.k file which is distributed with LS-DYNA 2024. still trying to fix the issue.
• May 30 the assertion error was causd by a piece of code that was leftover from previous development. I submetted a pull request to fix the issue. Now working on unexpected command *Part_ADAPTIVE_FAILURE which isn't a part it is an attribute related to a part which tells the solver to do an adaptive mesh on this part starting at a certain time step.
• May 31 writing a code to handle Part_ADAPTIVE_FAILURE command in LS-DYNA, this is not actually a part it is a property related to a part, namily it tells which part is subject to adaptive mesh and when the adabtive mesh should start.
• June 1 trying to add attributes to regions.
• June 2 found a solution to add the attributes to the region, now preparing the code to submit a pull request.
• June 3 Created a pull request to handle Unexpected command *PART_ADAPTIVE_FAILURE. we decided to add it as an attribute to the BOT.
• June 4 modifying yesterday's pull request.
• June 5 I wrote the code to add the PART_ADAPTIVE_FAILURE as an attribute to the region and to the BOT, but now I am getting access violation errors. trying to debug.
• June 6 did some modification on the PART_ADAPTIVE_FAILURE pull request, and now working on other bugs.
• June 7 did some modification on the PART_ADAPTIVE_FAILURE pull request and working on the a bug related to nodes coordinates in LS-DYNA being too small to represent using double.
• June 8 did some modification on the PART_ADAPTIVE_FAILURE pull request, and found that the bug related to nodes coordinates is not caused by very small numbers but because of the encoding of the file I was trying to convert.
• June 9 the problem with the enconding is realted to the way the key file format is organized, the nodes coordinates has the following format I8,3E16.0,2F8.0, now working on a new parsing function for the node coordinates to include all possible cases.
• June 10 I created two implementations to handle the standard format and doing some research in the documentation to understand all possible formats.
• June 11 submitted a pull request for read_line_node_standard(). now I will organize the ideas from LS-DYNA documentation in order to include all possible formats.
• June 12 I figured out the formats: Ls-Dyna Has 3 formats Standard, Long and I10, Standard for *Node is I8,3E16.0,2F8.0. in the Long format every field that was less or equal to 20 charachters in the standard format becomes 20 caracters and any field that was longer than 20 becomes 160 which makes the *Node I20,3E20.0,2F20. while the I10 extends any 8 characher field in the standard format to 10 charachter field so node becomes I10,3E16.0,2F10. This is what LS-PrePost can write. While it can read the same ubove mentioned formats as they are and also comma separated. which they call free format. but it's not possible to write a file with comma separated fields.In older versions (also old documentation) when the long format is invoked, the number of lines belonging to the *Node key word becomes two lines instead of one. while in the new versions the number of lines is one for either standard or long formats.the signs (+) for (long) and (-) for (standard) are not writtine by LS-PrePost when the file is saved. but can be used by the user in the command line or if they user has written his own .key file. consequently these formats can be mixed by the author of the .key file for example *Node+ (some node) *Node-(some other node). A file written by LS-PrePost in the long format can be distingueshe by LONG=Y written after the *Keyword, while nothing is written after the *NODE
• June 13 I wrote code to handle different format. still not ready to make a pull request.
• June 14 submitted a pull request to handle the different reading formats.
• June 15 it is mensioned in the documentation (old versions 2012) that when the long format is invoked the *NODE will be split into 2 lines. I have been trying to reproduce this case with no sucess.
• June 16 modified the pull request to include two line node format.
• June 17 wrote the code to handle the non defult format where the zeros are replaced by spaces.
• June 18 I updated the pull request to count for comma separated file format, and the non default format.
• June 19 studying the code to handle the unhandeled command *ElEMENT_SOLID.
• June 20 studying the code to handle the unhandeled command *ElEMENT_SOLID.
• June 21 I more or less figured out how to handle the solid elements, I have to creat a solid struct where to store all the solid element properties parsed from the .key file then on the other side I have to creat functions to write the element as arb4, arb6 or arb8 . starting to develope the code today
• June 22 I have put a plan for developing ELEMENT_SOLID and added solid.h and solid.cpp to the buildig system.