Difference between revisions of "Ali Haydar Dev log 2024"
From BRL-CAD
Ali Haydar (talk | contribs) (→Coding period) |
Ali Haydar (talk | contribs) (→Coding period) |
||
Line 16: | Line 16: | ||
* 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 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 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. |
Revision as of 13:59, 9 June 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.