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.
• June 23 Developing Element Solid.
• June 24 Developing Element Solid.
• June 25 Developing Element Solid.
• June 26 on the side of parsing the element solid is ready no I need to figure out how to write it to an intermediate structure.
• June 28 strugling to add arb8 to the data base, in the code there seems to be multiple ways to do that.
• June 29 I wrote a prlimanry code to write the arb into the data base then adding all the arbs into a single reagion.
• June 30 tody is for writing the code from yesterday into the class Solid. we decided on different configuration. I wrote the class Arb and I was going to put inside a class Solid which will behave as a fake Bag of arbs then put Bot class and Solid inside a super calss Geometry.
• July 1 I wrote the code and submitted a pull reqest to check with mentors about which classes should I implement for dealing with the solid element.
• July 2 sick day.
• July 3 I updated the pull request with Arbs class, and did the necessary modifications for writing the arbs.
• July 4 submitted a small pull request related to case insensitive keywords. I was checking some examples from ls-dyna to plan on what to implement after element solid, I found the sloshing example has keywords that are not implemented like *MESH_SURFACE_ELEMENT and *ICFD_PART, although i didn't find anything on this commands in the documentation. but it's possible to convert them if we include these keywords and the elmements are almost like triangular shell elements.
• July 5 Implementd a Geomtry class to incapsulate the geometry of an LS-DYNA part.
• July 6 working on the Geomtry class.
• July 7 updated the caseinsensitve keywords pull request and did some test for conversion of special charachters using toupper() function. I also read some documentation to plan for future development.
• July 8 Working on Geometry class. and will update the pull request.
• July 9 Working on Geometry class.
• July 10 updated the pull request with Geomtry.write() function still need some work
• July 11 working on missing commands . found a bug realted to freeeing the Bot object it was getting freed twice. now everything is fine .
• July 12 I am working on a pull request to handle *ElEMENT_BEAM, *ELEMENT_DISCRETE , *ELEMENT_MASS, *SECTION_BEAM and *SECTION_DISCRETE.
• July 13 still stuck in yesterday's pull request and the Geometry class, it doesn't seem that I am naming the objects correctly or sometimes I name them twice.
• July 14 updated the pull request for Geomtry class.
• July 15 writing code to handle *PART_CONTACT *SECTION_BEAM *SECTION_DISCRETE *ELEMENT_MASS and I notecied that we need to have additional functions to read element and section properties similar to read_line_node_standard() function.
• July 16-20 I was outside of Italy and didn't have working permession, I will subliment these days after the end of the program.
• July 21 working on closing the geomtry class pull request and handling the missing commands. I cleaned up the pull request. and currently handling other types of arb like arb4, arb5...etc
• July 22 working on some errors in the Geometry PR
• July 23 working on missing commands.
• July 24 working on Geometry class. and prepargin a pull request for the missing commands but it relies on the geometry PR so I will submite it after colsing that one.
• July 25 working on Geomtry class and unhandeled commands.
• July 26 working on unhandeled commands, I am trying to creat a general implimentation of commands, where the distinction between two different commands and a command with options. also the options can override other properties related to the geometry, this needs to be prserved based on the priority of the command or the options.
• July 27 submitted a pull request to make a distinction between a command and it's options, the code will be useful also for handling all kinds of elements in LS-DYNA.
• July 28 working on unhandeled commands and options.
• July 29 a new implementaion of options is in order to handle the precedency of options or commands. I am also working on ELEMENT_BEAM implementation in BRL-CAD where I need to extrude the section to a solid.
• July 30 I actully found out that the strategy we are following is not totally accurate, giving that when we switch on the sectionLinesRead we are assuming a certain order of the cards which is not true. I am developing a solution which involves using sectionLinesRead and an enum of section options.
• July 31 I submitted a solution for the element options.
• August 1 working on handling element_beam options
• August 2 preaparing the pull request for element beam options and working on random coloring for the regions.
• August 3 finished modifications and submitted the pull request.
• August 4 working on the optinos and coloring of the reagions.
• August 5 submitted a pull request for reagion colors, and implemented the element Pulley on the parser side.
• August 6 implementing elements on the parser side
• August 7 implementing elements on the parser side
• August 8 implementing sections on the parser side
• August 9 updated the pull request with section beam on the parser side.
• August 10 working on the Brlcad side for the element beam.
• August 11 working on the Brlcad side for the element beam.
• August 12 working on the Brlcad side for the element beam.
• August 13 impliminting the beam element with section type (CST= 1)Tubular (circular only) as a pipe primative.
• August 14 created a Beam class where I am planning to store the information related to the beam then writing them to the data base.
• August 15 implemented beam elmeent with section type 1 as pipe premative. There are still some issues with the PR.
• August 16 working on fixing the problems with the privous pull request, I am unable to export the pipe premative when it has more than two points.