| Latest revision |
Your text |
| Line 11: |
Line 11: |
| | * June 2 found a solution to add the attributes to the region, now preparing the code to submit a pull request. | | * 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 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.
| |
