Daniel Rossberg (Apr 20 2024 at 14:39): Daniel Rossberg (Apr 20 2024 at 14:39):Hi @Louis Googl, I created a pull request with a new version of the k-g converter: https://github.com/BRL-CAD/brlcad/pull/127 Please, review it, test it on Windows, and compare it with the old one. Would you recommend to replace the old k-g with this new one?
Louis Googl (Apr 20 2024 at 15:02):Hello @Daniel Rossberg , I will start with it today.
Louis Googl (Apr 24 2024 at 11:55):Hi @Daniel Rossberg , I have done some testing and found some issues,
1- if the part name contains a space the reagion name will contain the space and it's not possible to draw that part separitly in mged
colorOftheBotsisthesame.png
2- all parts has the same color which isn't the case in the old k-g also the space in the name is replaced by an underscore
OLDDifferentColorsNospaceinPartName.png
3- while trying to convert a .k file which is distributed with LS-Dyna 2023 I encountard an assertion error in the new k-g, which didn't happen in the old one
assertionFaild.png
OLDNoassertionErrorSPR4.png
4- another .k file distributed as example produces an unhandeled exception in the new k-g while it is converted normally with the old k-g
unhandeledException.png
oldVersionCanConvertBucklingFilewithDifferentColors.png
5- *ElEMENT_SOLID and *SECTION_SOLID_TITLE are unhandeled in the new version
unexpectedComand.png
as also was mentioned by @starseeker on GitHub
Louis Googl (Apr 24 2024 at 12:01):the first issue is easy to handle using std::replace
image.png
Louis Googl (Apr 24 2024 at 12:11):Regarding the other issues, I can work on fixing them if you think it's a good improvment. Regarding the comparison with the old version, I still need to read the code more thoroughly, but despite the issues the new code is much more organized and clear, also the definition of parsing logic in the k_parser.cpp is much more convinent, same for region_list.cpp. I think this is the correct way to go after fixing the issues and implementation of *ELEMENT_SOLID.
Louis Googl (Apr 24 2024 at 12:12):just for the future, do prefer that I write a document instead of sending long massages here?
Sean (Apr 24 2024 at 16:41):You have to put the object name in quotes if it has a space
Sean (Apr 24 2024 at 16:42):draw "this object"
Daniel Rossberg (Apr 24 2024 at 16:56):Louis Googl said:
Regarding the other issues, I can work on fixing them if you think it's a good improvment. Regarding the comparison with the old version, I still need to read the code more thoroughly, but despite the issues the new code is much more organized and clear, also the definition of parsing logic in the k_parser.cpp is much more convinent, same for region_list.cpp. I think this is the correct way to go after fixing the issues and implementation of *ELEMENT_SOLID.
You could still find the old k-g.cpp in the version control system, but because of all the shortcomings, I make it the git way: I created a new branch devel_k-g with the new converter. You can use this as the base for your development and send your pull requests there. I'll keep my hands off as long as you work on it.
Daniel Rossberg (Apr 24 2024 at 16:58):The new k-g is a back-port from a brlcad.dll application. There, some things are different. And, I had only one file to test :wink: I don't have LS-Dyna.
Daniel Rossberg (Apr 24 2024 at 17:01):Sean said:
You have to put the object name in quotes if it has a space
@Louis Googl, if possible, keep the names as they are. This makes it easier to maintain the part list for both sides.
Sean (Apr 24 2024 at 17:06):On BRL-CAD's side, just about anything is allowed in names .. to a fault even as handling spaces/slashes/quotes will vary from command to command. Most do handle spaces if they're quoted though, just like shell. But at the database level, it's anything up to the nul character.
Sean (Apr 24 2024 at 17:14):There are a few helper functions like bu_vls_encode()+bu_vls_decode() to wrap in quotes, and bu_vls_simplify() to automatically replace unwanted chars, and bu_str_escape()+bu_str_unexscape() to manage levels of escape sequences.
Louis Googl (Apr 24 2024 at 20:07):Daniel Rossberg said:
You could still find the old k-g.cpp in the version control system, but because of all the shortcomings, I make it the git way: I created a new branch devel_k-g with the new converter. You can use this as the base for your development and send your pull requests there. I'll keep my hands off as long as you work on it.
that is great, I will continue the testing and comparison so I understand better, then I will start the implemention.
Louis Googl (Apr 24 2024 at 20:11):Daniel Rossberg said:
The new k-g is a back-port from a brlcad.dll application. There, some things are different. And, I had only one file to test :wink: I don't have LS-Dyna.
what do you mean by back-port?
Louis Googl (Apr 24 2024 at 20:15):Sean said:
There are a few helper functions like bu_vls_encode()+bu_vls_decode() to wrap in quotes, and bu_vls_simplify() to automatically replace unwanted chars, and bu_str_escape()+bu_str_unexscape() to manage levels of escape sequences.
Thank you for the information @Sean.
Daniel Rossberg (Apr 25 2024 at 06:45):Louis Googl said:
Daniel Rossberg said:
The new k-g is a back-port from a brlcad.dll application. There, some things are different. And, I had only one file to test :wink: I don't have LS-Dyna.
what do you mean by back-port?
Usually, I don't program directly on the BRL-CAD core, but use the C++ API.
Vidit Jain (May 01 2024 at 19:39):I just got mail from GSOC that proposal have been accepted.. Thanks a lot @Sean @Daniel Rossberg @Himanshu Sekhar Nayak
I will give my best to the organization. It means a lot to me
Vidit Jain (May 01 2024 at 19:40)::heart:
Louis Googl (May 02 2024 at 08:40):I also got the email from GSOC, I am glad that my project is accepted and even more glad to get to work with you again @Daniel Rossberg @Sean, thank you.
Sean (May 05 2024 at 12:32):@Louis Googl Likewise, very much looking forward to working with you again and all that you're planning on working on. Coupling cad to cae/cam is pretty darn important, but you have the experience for it!
Louis Googl (May 05 2024 at 16:15):@Sean it is indeed important, I will do my best to have a nice project with you and GSOC. On another note I am intersted in your idea realted to Ray tracing and FE solvers or multi body dynamics solvers, maybe if you will have some time we can talk about it.
Daniel Rossberg (May 27 2024 at 07:07):@Louis Googl, meanwhile, there where some changes in the main branch on how brlcad is build. Please tell me, if I should merge these into devel_k-g.
Louis Googl (May 27 2024 at 07:53):Yes, can you please merge the changes into devel_k-g. I think it's better if the building process is the same.
Daniel Rossberg (May 27 2024 at 11:22):Okay, done.
Louis Googl (May 27 2024 at 19:15):well...I had the feeling this will come back and bit me, the configuration has faild on windows and ubuntu, where can I check for the new building procedure?
WhatsApp-Image-2024-05-27-at-6.10.10-PM.jpeg
propably the windows error is my fault I am reinstalling all developing tools
Louis Googl (May 27 2024 at 19:15):but the ubunto seems more complicated
Screenshot-from-2024-05-27-21-05-53.png
Screenshot-from-2024-05-27-21-14-20.png
I need some help please.
Daniel Rossberg (May 27 2024 at 20:10):MaBe, this https://brlcad.zulipchat.com/#narrow/stream/104062-brlcad/topic/build can help.
starseeker (May 27 2024 at 21:59):a3e80727663b0 I think will help with that error - the warning is OK.
Daniel Rossberg (May 28 2024 at 06:36):starseeker said:
a3e80727663b0 I think will help with that error - the warning is OK.
Merged into devel_k-g.
Louis Googl (May 28 2024 at 06:47):thank you, I will let you know how it goes .
Louis Googl (May 28 2024 at 20:35):I have successful build on windows and ubuntu, thank you for help. I am starting to fix the bugs
Louis Googl (May 29 2024 at 21:06):I found the reason for the assertion error when converting this file
spr4.k, first when you find a triangle in the first part
image.png
the new iterator it_ is pointing to something it shouldn't point to
image.png
I tried putting a condition to avoid this problem but still there is another assertion error when adding the triangle
image.png
Louis Googl (May 29 2024 at 21:12):trying to find the reason. but still it's not obvious to me why do you want to go back to the previous part when you find a triangle.
Daniel Rossberg (May 30 2024 at 13:03):I could imagine, that this is a left-over from development. Have you tried it without this code?
Louis Googl (May 30 2024 at 13:04):yes it works perfectly without that part. should I delete it?
Daniel Rossberg (May 30 2024 at 13:04):If it woks with your test files: Yes.
Daniel Rossberg (May 30 2024 at 13:05):I'm just compiling the devel_k-g branch. It needs some time.
Louis Googl (May 30 2024 at 13:11):image.png
yes, the conversion on spr4.k works without this piece of code.
still the unexpeted command which I will get to after
image.png
Louis Googl (May 30 2024 at 13:12):Daniel Rossberg said:
I'm just compiling the devel_k-g branch. It needs some time.
take your time. no worries
Daniel Rossberg (May 30 2024 at 13:26):Regarding unexpected commands: This are commands, currently not handled by the program. I.e., you have to write the code which handles them. What is a PART_ADAPTIVE_FAILURE?
Louis Googl (May 30 2024 at 13:31):yes, I will write a code to handle all unexpected comands. Part_ADAPTIVE_FAILURE isn't a part it seems to be a property of part 4.
image.png
it doesn't have similar properties to other parts like secid, mid and eosid ..etc
image.png
Louis Googl (May 30 2024 at 13:32):I am looking around to see exactly what is it.
Louis Googl (May 30 2024 at 13:32):should I prepare a pull request to remove the code that is causing the problem?
Louis Googl (May 30 2024 at 13:37):Louis Googl said:
I am looking around to see exactly what is it.
image.png
found it, it tells which part have adaptive meshing and when it starts hence the properties are pid (part id) and t (adaptive mesh starting time)
Daniel Rossberg (May 30 2024 at 13:49):Louis Googl said:
should I prepare a pull request to remove the code that is causing the problem?
Yes, I'm keen to see it.
Louis Googl (May 30 2024 at 13:53):I will do some more tests and prepare the pull request. thanks
Daniel Rossberg (May 30 2024 at 14:01):Louis Googl said:
Louis Googl said:
I am looking around to see exactly what is it.
image.png
found it, it tells which part have adaptive meshing and when it starts hence the properties are pid (part id) and t (adaptive mesh starting time)
Therefore, it is something non-geometric. We could ignore it - or write it as an attribute in the region. See https://github.com/BRL-CAD/MOOSE/blob/main/src/Database/Object.cpp for some example code on how to read and write attributes (e.g., look at how SetAttribute() is implemented).
Louis Googl (May 30 2024 at 14:04):I will check it out. and prepare separate pull request for it.
Louis Googl (May 30 2024 at 15:44):@Daniel Rossberg I have created a pull request. please let me know if you have any notes
Daniel Rossberg (May 30 2024 at 16:45):Louis Googl said:
Daniel Rossberg I have created a pull request. please let me know if you have any notes
:)))) Why not
if (n3 == n4)
add one bot
else
add two bots
(this is pseudo code, of course). There is no need for partOnlyOfTriangles/triangularElement, isn't it?
Louis Googl (May 30 2024 at 16:53):I had the idea but using bool seemed cooler :sweat_smile:. You are right there is no need for triangularElement. I will resubmit
Louis Googl (May 30 2024 at 16:55):Is it okay if I add a comment? clarifying that when n3=n4 the element is triangular. Maybe it's not common knowledge
Daniel Rossberg (May 30 2024 at 17:03):It's okay, but the code says it too. However...
Louis Googl (May 30 2024 at 18:05):done. new pull request
Louis Googl (Jun 01 2024 at 10:36):Daniel Rossberg said:
Therefore, it is something non-geometric. We could ignore it - or write it as an attribute in the region. See https://github.com/BRL-CAD/MOOSE/blob/main/src/Database/Object.cpp for some example code on how to read and write attributes (e.g., look at how SetAttribute() is implemented).
I was working on this, the easy way would be to ignore it but I chose the hard way ( write it as an attribute in the region) because we might encountre attributes that we can't ignore and I would like to learn how to add an attribute.
while reading the object.cpp which is a part of MOOSE, I searched for equivelent operation in BRL-CAD, I found them in avs.c/avs.h like
bu_avs_add(struct bu_attribute_value_set *avsp, const char *name, const char *value)
but the thing I don't know how to do is where to write the attribute set. I checked the region structure it seems the region has its own properties
1_name_headp_mat_op.png
2_combproperties.png
like material for example.
Louis Googl (Jun 01 2024 at 10:40):I was searching how bu_avs_get() is used and found something in matter.cpp, but still I don't understand how to add an attribute to the reagion.
image.png
Louis Googl (Jun 01 2024 at 10:41):@Daniel Rossberg Can you give me some hints please. and if you have some notes on the startegy I followed please let me know if this is the correct way to approach a problem.
Daniel Rossberg (Jun 01 2024 at 12:03):I pointed you to Object.cpp in MOOSE, because it contains examples on how to use bu_avs_add(), for example. If you look at Object::SetAttribute() and following its code at Object::GetAvs() you may come up with something like
//(rt_db_internal*)ip
//(const char*)key
//(const char*)value
bu_avs_add(ip->idb_avs, key, value);
This can be done for every BRL-CAD database object, including combinations.
Louis Googl (Jun 01 2024 at 20:38):thank you for the help.
I did something like this
struct rt_db_internal region_internal;
struct directory* dp ;
struct db_i *dbip ;
bu_attribute_value_set* avs;
dbip = wdbp->dbip;
dp = db_lookup(dbip, region_name.c_str(), 0);//after the reagion was created
rt_db_get_internal(®ion_internal, dp, dbip, bn_mat_identity, &rt_uniresource);
avs = ®ion_internal.idb_avs;
const char* key= "adabtive_Mesh";
const char* value= "0.2";
bu_avs_add(avs, key, value);
but I don't see the attributes when I use the (l) command in Mged. what do you think?
starseeker (Jun 01 2024 at 22:58):You have to write the updated attributes back to the database. See the attr set command, for example: https://github.com/BRL-CAD/brlcad/blob/1d5773d243fc4f0de96cfd7d2186686c55514b16/src/librt/attr.cpp#L612
Louis Googl (Jun 02 2024 at 10:33):it works :tada:
image.png
Louis Googl (Jun 02 2024 at 10:34):@Daniel Rossberg I will clean the code and submite a pull request.
Louis Googl (Jun 03 2024 at 15:28):I created a pull request to handle *PART_ADAPTIVE_FAILURE, pull.
Louis Googl (Jun 03 2024 at 15:29):It is much bigger than I expected, and I assume there is some mistakes, but I checked that it build and converts correctly and the addition of the attribute to the BOT appears in Mged.
Louis Googl (Jun 03 2024 at 15:34):one mistake that I know of is the handeling of unintialized bu_attribute_value_pair. the else statment in the following picture.
image.png
Louis Googl (Jun 03 2024 at 15:35):but still I don't know if the entire idea is correct. please let me know what do you think.
Daniel Rossberg (Jun 03 2024 at 17:57):How about adding std::map<std::string, std::string> attributes; to KPart. This would make it more general and reusable, in case there will be more than one attribute.
In addition, the attributes should be written into the region. Therefore, RegionList should get this map too, and a setAttribues() method. (Or, addRegion() an additional parameter?)
Finaly, RegionList::create() should write the attributes into the BRL-CAD database.
Louis Googl (Jun 03 2024 at 18:28):Surely the map is better, we will need to add the color attribute also. I will work on adding the attributes to the region too.
Louis Googl (Jun 04 2024 at 16:16):I just relized that the region_list already contains the attributs in the bot, we just need to wirte them to the data base . or I would creat an attribute list inside region list and creat setAttrebutes(), getAttributes(), and writeAttributes().
image.png
Louis Googl (Jun 04 2024 at 16:16):which way do you think is better?
Daniel Rossberg (Jun 04 2024 at 16:55):Ah, interesting.
The attributes have to go into the region (combination), i.e. the object created with mk_lfcomb() in RegionList::create().
And, you are right, the region list ha to be extended. Currently, it has the member std::map<std::string, Bot> m_list;, where std::string are the names of the regions and Bot are the affiliated bots. With attributes, you could do:
struct Region {
Bot bot;
std::map<std::string, std::string> attributes;
};
class RegionList {
....
private
std::map<std::string, Region> m_list;
};
or
struct Region {
Bot bot;
std::map<std::string, std::string>* attributes;
Region(void) : bot(), attributes(nullptr) {}
};
for example.
Louis Googl (Jun 04 2024 at 18:04):That's nicer, working on it.
Kampanat Thumwong (Jun 04 2024 at 18:14):KAMPANAT THUMWONG
Louis Googl (Jun 05 2024 at 16:34):I created a new pull request . I followed this approach
struct Region {
Bot bot;
std::map<std::string, std::string> attributes;
};
class RegionList {
....
private
std::map<std::string, Region> m_list;
};
but now I am getting an Access violation error when freeing the BOTs, I think it's becaue now the bot gets deleted by Region before getting deleted by it's own destructor Bot::~Bot(void) . or am I wrong?
Louis Googl (Jun 05 2024 at 16:40):trying to fix this error, if you have any suggestions please let me know.
Louis Googl (Jun 05 2024 at 17:19):I found the problem. I will fix the pull reqest and send it again
Louis Googl (Jun 05 2024 at 17:29):fixed. let me know if it needs any modifications.
Daniel Rossberg (Jun 06 2024 at 07:50):Okay, some first comments:
Louis Googl (Jun 06 2024 at 08:27):1- working on it.
2- K-Parser now doesn't do anything with the database
image.png
image.png
image.png
I am storing the attributes in
KData& data
data.parts[pid].attributes["ADAPTIVE_FAILURE_STARTING_TIME"]=tokens[1];
which is the intermediate data structure. or am I worng?
Louis Googl (Jun 06 2024 at 08:29): Daniel Rossberg (Jun 06 2024 at 09:01):Louis Googl said:
1- working on it.
2- K-Parser now doesn't do anything with the database
image.png
image.png
image.png
I am storing the attributes inKData& data data.parts[pid].attributes["ADAPTIVE_FAILURE_STARTING_TIME"]=tokens[1];which is the intermediate data structure. or am I worng?
You are right, K-Parser doesn't touch the database. I got something wrong there. Sorry for that.
Louis Googl (Jun 06 2024 at 09:03):No worries, I will finish the 3rd point and update the pull request. thank you for the notes.
Louis Googl (Jun 06 2024 at 10:00):@Daniel Rossberg New pull request.
Daniel Rossberg (Jun 06 2024 at 16:12):I have some remarks. When I see code ... :crazy:
Louis Googl (Jun 06 2024 at 17:33):I saw the comments, I will fix them tonight so I can do something new tomorrow
Louis Googl (Jun 06 2024 at 19:28):new Pull
Louis Googl (Jun 06 2024 at 19:32):you asked about why PART_ADAPTIVE_FAILURE_STARTING_TIME?
its because the attribute Part_Adaptive_Failure in LS-DYNA refers to the time when the adaptive mesh should start. we could call it ADAPTIVE_FAILURE_MESH_STARTING_TIME. I am open for any other suggestions
image.png
Daniel Rossberg (Jun 06 2024 at 19:48):My question was whether to start the flag with PART_ or not.
Louis Googl (Jun 06 2024 at 20:07):Now I understand, sorry I read it fast. If we add PART_ it's more clear. I will modify it
Louis Googl (Jun 06 2024 at 21:34): Louis Googl (Jun 07 2024 at 15:23):I found the bug related to the conversion of this key file
image.png
Louis Googl (Jun 07 2024 at 15:24):image.png
some nodes has very small values for the coordinates, which are out of the rang of std::stod()
Louis Googl (Jun 07 2024 at 15:26):I am working on a fix
Daniel Rossberg (Jun 07 2024 at 16:46):Louis Googl said:
You do not need to create a new pull request after every change. Instead, you can update your old one. The usual work-flow is:
git checkout -b my_devel_k-g devel_k-g (i.e., it inherits the devel_k-g branch)In case you want to update your pull request:
Louis Googl (Jun 07 2024 at 17:13):I knew I was doing something wrong :sweat_smile:. I will follow this work flow from now on, thank you.
Vidit Jain (Jun 07 2024 at 17:54):(deleted)
Louis Googl (Jun 07 2024 at 19:41):I modifeid the pull request.
Daniel Rossberg (Jun 08 2024 at 15:29):Okay, one point left open: To check the success of rt_db_get_internal and maybe db_lookup. See my comment in the PR.
Louis Googl (Jun 08 2024 at 15:49):I saw the comment, I will modify it tonight
Louis Googl (Jun 08 2024 at 15:50):Louis Googl said:
I found the bug related to the conversion of this key file
image.png
What do you think about this one ?
Daniel Rossberg (Jun 08 2024 at 16:26):Louis Googl said:
I am working on a fix
I've read this ... and no questions anymore.
Daniel Rossberg (Jun 08 2024 at 16:28):It seems to be an issue of the C/C++ parser with numbers other than doubles.
Louis Googl (Jun 08 2024 at 16:56):I was implicitly asking if it's a good thing to work on :sweat_smile:. I Should have asked more clearly.
Sean (Jun 08 2024 at 18:49):That's a pretty extreme small number...
Louis Googl (Jun 08 2024 at 19:15):I also find it weird but the file I am using B3_Frame_linear_buckl.key is distributed with LS-DYNA as an example and the old k-g converter was able to convert it with no problems.
Daniel Rossberg (Jun 08 2024 at 20:38):Upon a closer look, there are numbers with two many dots. Obviously, the numbers are not space separated, but have fix positions in the lines ("FORTRAN format"). Do you know which?
Higher precision than double would be unexpected. Such kind of simulations often work with float precision only, for less memory consumption and higher speed.
Daniel Rossberg (Jun 08 2024 at 20:41):Eight characters per number, does this make sense?
Louis Googl (Jun 08 2024 at 21:47):I was just going to text. I thought that the file was currpted when opening it on LS-DYNA and saving it again the file converts correctly with the new k-g converter.
Louis Googl (Jun 08 2024 at 21:50):Daniel Rossberg said:
Eight characters per number, does this make sense?
image.png
I don't think so, as you can see in the photo it doesn't seem to have any pattern
Louis Googl (Jun 08 2024 at 21:54):image.png
This is the same file after I resaved it using LS-PrePost
Louis Googl (Jun 08 2024 at 22:02):well I found a pattern the numbers maximaly take 16 characters each
Louis Googl (Jun 08 2024 at 22:04):but the node ID takes 8 characters
Louis Googl (Jun 08 2024 at 22:11):should I modify parse_line() to include this case, or catch the exception and ask the user to resave the file?
Daniel Rossberg (Jun 09 2024 at 12:20):It looks like the NODE needs a special 8-16-16-... parser. Even the resaved file follows this pattern. You can reparse line in KState::Node.
What does the documentation say, do all lines with numbers follow this pattern?
Louis Googl (Jun 09 2024 at 13:43):I am checking out the documentations. first find the input is case insensitve
image.png
Louis Googl (Jun 09 2024 at 13:44):for the numbers format I am trying to understand. there are mutiple cases
Vidit Jain (Jun 09 2024 at 14:02):(deleted)
Louis Googl (Jun 09 2024 at 14:15):the format is I8,3E16.0,2F8.0 but the node key word is not followed by ( - ) as shown in the documentation
image.png
image.png
Louis Googl (Jun 09 2024 at 16:20):(deleted)
Daniel Rossberg (Jun 09 2024 at 16:24):Sounds good, you have something to do :wink:
Daniel Rossberg (Jun 09 2024 at 16:25):What I don't understand is: We get the standard format without the "-" after NODE :thinking:
Louis Googl (Jun 09 2024 at 16:27):this is more clear
image.png
Louis Googl (Jun 09 2024 at 16:28):Daniel Rossberg said:
Sounds good, you have something to do :wink:
- Case insensitive check of the key-words
- Implement a read_line_node_standard() (or similar), which is called in the Node state
there are more things to do also realted to format :octopus:
image.png
Daniel Rossberg (Jun 10 2024 at 16:39):So, there are two formats for the NODEs: standard and long. What's default, can be set with the KEYWORD command, and can be set individually for every NODE section by adding a + or -, right?
Louis Googl (Jun 10 2024 at 16:40):that is what I understood from the documentation. but I havent yet found any file where the node keyword is followd by - or +.
Louis Googl (Jun 10 2024 at 16:44):I am writing the code for the standard case, and I will try to creat a file with the long format in LS-PrePost. then I will check if its possible to see the (+) in the key file
Daniel Rossberg (Jun 10 2024 at 16:48):Louis Googl said:
that is what I understood from the documentation. but I havent yet found any file where the node keyword is followd by - or +.
Okay, that's not optimal.
But, in case we want to handle this, we would need two status variables:
and a line counter "nodeLinesRead". But then, could it me merged with "partLinesRead" and "sectionLinesRead" to a general "linesRead"?
Louis Googl (Jun 10 2024 at 16:55):I don't think it can be merged to a general linesRead because the format could change from "Card" to another, so a node could occupy a single line or occupy two lines. but maybe we can increase the step of linesReed accourdingly
image.png
Louis Googl (Jun 10 2024 at 16:57):also there is the fixed format which is comma separated.
Louis Googl (Jun 10 2024 at 17:15):I came up with two implementations and tested them 1:
image.png
image.png
Louis Googl (Jun 10 2024 at 17:16):
Louis Googl (Jun 10 2024 at 17:16):what do you think? any of them is good?
Daniel Rossberg (Jun 10 2024 at 18:38):The first one is easier to understand, but the second one is better because you check the length of the line there.
Louis Googl (Jun 10 2024 at 21:16):Okay, I will prepare a pull request with the second one. What about the hard coded numbers. Is it fine like that?
Daniel Rossberg (Jun 11 2024 at 06:47):Yeah, this are fixed, well defined formats. Therefore, hardcoded numbers are okay.
Louis Googl (Jun 11 2024 at 13:14):I created a PR for the standard format. now I will organize the ideas from the documentations to include all possible formats (fixed, free, long...etc)
Louis Googl (Jun 11 2024 at 13:14):I will also prepare a pull requst for the case insensitive commands.
Louis Googl (Jun 12 2024 at 16:07):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
Louis Googl (Jun 12 2024 at 16:09):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.
Louis Googl (Jun 12 2024 at 16:13):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.
Louis Googl (Jun 12 2024 at 16:20):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)
Louis Googl (Jun 12 2024 at 16:23):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
image.png
image.png
image.png
Louis Googl (Jun 12 2024 at 16:27):while a file saved in the I10 format can be distingushed by I10=Y written after the *Keyword or the percentage sign written after *NODE %
image.png
image.png
image.png
Daniel Rossberg (Jun 12 2024 at 16:30):Okey, therefore we need
Louis Googl (Jun 12 2024 at 16:44):do we want to read anything LS-PrePost can read or only the things that it can save? because
Long=Y means (read long write long), Long=s means (read standard write long) , long=k means ( read long write standard). what about the comma separated case should we implement it?
Louis Googl (Jun 12 2024 at 16:50):yes we need nodeHalfLine variable if we want to read older versions with long format.
Daniel Rossberg (Jun 12 2024 at 17:26):Ideally, we should be able to read everything what's a valid key-file...
Louis Googl (Jun 12 2024 at 18:18):Okay, I will work on the points you mentioned then we can plan for the other points
Louis Googl (Jun 14 2024 at 12:22):I have submitted a draft pull request so you can see the way things are going, and I don't go very far in the wrong direction :grinning_face_with_smiling_eyes: .
I think it's better insetead of defaultNodeFormat to put File format, because the *KEYWORD defines the format for the entire file, then I defined a node format to test for each node if it's format corresponds to the file format or not. This is a thing we can do to all other Blocs/Cards. I tested the code using the saving formats from LS-PrePost (standard, Long,I10), and I modified a standard file to include a long node
image.png
Louis Googl (Jun 14 2024 at 12:25):Now I am trying to get an old version of LS-PrePost to prepare the code for nodeHalfLine;
Daniel Rossberg (Jun 15 2024 at 13:15):You code looks good. I added some comments, how it could be improved, but your direction is the right one.
Louis Googl (Jun 15 2024 at 20:27):I have been trying to reproduce a node with two lines for the entire day. No sucess even if I write it by myself the LS-PrePost gives an error. should I just take the documentations word for it and write the code correspondingly, or keep trying to find a file with two lines nodes?
Daniel Rossberg (Jun 16 2024 at 15:13):I would say, do your best and implement it following the documentation. We will probably never see a LS-Dyna keyword file with the 2-line node format in real live.
Louis Googl (Jun 16 2024 at 15:20):okay, I will do it following the documentations.
Louis Googl (Jun 16 2024 at 15:26):while playing with the save options I found an addtional case, the option Non-Default Only, the format doesn't change but the zero fileds are replaced by spaces
image.png
image.png
Louis Googl (Jun 16 2024 at 15:35):I also found the option for saving the file in Freeformat, sorry that I said it wasn't possible before.
In Freeformat the zeros aren't recorded as you see in the picture, and if the zero fields are the end they aren't even delimenated by commas.
image.png
image.png
image.png
Louis Googl (Jun 16 2024 at 15:37):I will prepare a pull requst for all these cases.
Daniel Rossberg (Jun 16 2024 at 16:25):Hmm, stod() of an empty string (or spaces only) should be 0, or throw an exception?
Louis Googl (Jun 16 2024 at 16:31):it throws an exception for both.
Louis Googl (Jun 18 2024 at 18:58):I updated the pull request to include the case where the node occupies two lines. also the comma separated format and the non default only format. take your time to check it out. In case the ideas are fine I will do more tests and clean up the code for final PR. meanwhile I will start working on the unhandeled command *ElEMENT_SOLID
Daniel Rossberg (Jun 23 2024 at 12:33):Well, PR #144 looks good. You can clean it up. I added only one comment regarding the comma separated format.
Louis Googl (Jun 23 2024 at 12:49):Great, I will prepare it tonight
Louis Googl (Jun 23 2024 at 20:01):I cleaned up the PR. hopfully :grinning_face_with_smiling_eyes:
Louis Googl (Jun 23 2024 at 20:04):Regarding the solid element we need to change some data structures or add a new one like KElement, here I added the extra noods, but they will not be used in case the element was shell. I keep it like this or define two new structs KElement_shell and KElement_solid?
Louis Googl (Jun 23 2024 at 20:07):and I think the solution for adding the element solid is using arb8, what do you think?
Louis Googl (Jun 25 2024 at 16:35):another doubt, the only important information in section_solid is the ID, the elform (Element formulation options) and aet (Ambient element type) has nothing to do with the geometry but if one wants to convert again from .g to .k they are important information, should we register them somewhere?
image.png
Louis Googl (Jun 25 2024 at 16:36):if you wish to see the development they are on my github in a new branch mydevel_k-g. still not ready for a pull request
Daniel Rossberg (Jun 26 2024 at 06:49):Sorry for not responding. It's a busy time currently, very stressful. I hope to find time to analyse it soon.
Louis Googl (Jun 26 2024 at 12:26):Yeah don't worry, I will just leave the doubts here. You can check it when it's convenient for you
Daniel Rossberg (Jun 27 2024 at 17:30):Louis Googl said:
Regarding the solid element we need to change some data structures or add a new one like KElement, here I added the extra noods, but they will not be used in case the element was shell. I keep it like this or define two new structs KElement_shell and KElement_solid?
struct KElement {
std::vector<int> nodes;
};
?
Daniel Rossberg (Jun 27 2024 at 17:32):Louis Googl said:
and I think the solution for adding the element solid is using arb8, what do you think?
Yes, it looks very much like an arb8, including its reduced versions arb4, ..., arb7.
Daniel Rossberg (Jun 27 2024 at 17:34):Louis Googl said:
another doubt, the only important information in section_solid is the ID, the elform (Element formulation options) and aet (Ambient element type) has nothing to do with the geometry but if one wants to convert again from .g to .k they are important information, should we register them somewhere?
image.png
Can you translate them to attributes?
Daniel Rossberg (Jun 27 2024 at 17:42):How about having a superclass Geometry of Bot and Arb8 (I would call it this, because it wraps this BRL-CAD object) with a member variable type, where you can get its type?
Louis Googl (Jun 27 2024 at 18:35):Yes it's possible to add them as attributes, but I will have to add them to the elements not to the region, because they are an attribute of the elements that have that section
Louis Googl (Jun 27 2024 at 18:37):The super class is a good idea, I will work on it. Thank you for the notes
Louis Googl (Jun 29 2024 at 15:11):I wrote a prilimenary code for creating the arbs and adding them into a region.
I have a question regarding the superclass Geometry, in order to creat the super class I need to have the class Solid already implmented then put Bot and Solid inside Geomtry? or should I delete the Bot class and the Geomtry class will include everything related to bot and solid?
image.png
Vidit Jain (Jun 30 2024 at 03:08):(deleted)
Daniel Rossberg (Jun 30 2024 at 14:22):Okay - I think we need to go a step back. Can a Part have mixed Shell and Solid Elements?
Daniel Rossberg (Jun 30 2024 at 14:28):In this case, from an API point of view, we would need in k-g.cpp, line 70:
Geometry& geometry = regions.addRegion(partName);
with methods geometry.setThickness(), geometry.addTriangle(point1, point2, point3), and geometry.addArb8(point1, point2, point3, point4, point5, point6, point7, point8, ).
Louis Googl (Jun 30 2024 at 15:02):Daniel Rossberg said:
Okay - I think we need to go a step back. Can a Part have mixed Shell and Solid Elements?
I will check this.
Louis Googl (Jun 30 2024 at 15:07):Daniel Rossberg said:
In this case, from an API point of view, we would need in k-g.cpp, line 70:
Geometry& geometry = regions.addRegion(partName);with methods
geometry.setThickness(),geometry.addTriangle(point1, point2, point3), andgeometry.addArb8(point1, point2, point3, point4, point5, point6, point7, point8, ).
I was writing an Arb class and a solid class that contains a fake Bag of Arbs which would be a vector of Arb inside the solid class. because If we want to have gemotry.addArb8(), we need a place to add it to. geomtry.addTriangle() adds the triangle to a BOT
Louis Googl (Jun 30 2024 at 15:12):also this is necessary if we want to write the arbs in regions.creat(). there should be Geomtry.write() similar to what is now bot.write(). so the m_list of RegionList should contain the bag of arbs and the bag of triangles. or am I worng?
Daniel Rossberg (Jun 30 2024 at 15:47):I think, you are going in the right direction. However, I like to speak in code ;)
class Solid {
public:
void setThickness(double value) {
bot.setThickness(value);
}
void addTriangle(const point_t& point1,
const point_t& point2,
const point_t& point3) {
bot.addTriangle(point1, point2, point3);
}
void addArb(const point_t& point1,
const point_t& point2,
const point_t& point3,
const point_t& point4,
const point_t& point5,
const point_t& point6,
const point_t& point7,
const point_t& point8) {
arbs.push_back(Arb(point1, point2, point3, point4, point5, point6, point7, point8));
}
void write(rt_wdb* wdbp) {
if (bot.notEmpty())
bot.write(wdbp);
for (std::vector<Arb>::const_iterator it = arbs.begin; it != arbs.end; ++it)
it->write(wdbp);
}
private:
Bot bot;
std::vector<Arb> arbs;
};
Is it this, what you have in mind? (The above sketched code is in no sense complete or functional.)
Louis Googl (Jun 30 2024 at 15:56):image.png
a part cannot contain two different kinds of elements
image.png
Louis Googl (Jun 30 2024 at 15:57):ls-Prepost created an additional part autormatically because I wrote a solid element in a part that had shell elements
Louis Googl (Jun 30 2024 at 16:09):what I have in mind is
class Arb {
public:
Arb(void);
~Arb(void);
void setName(const char* value);
void addNodes(
const point_t& point1,
const point_t& point2,
const point_t& point3,
const point_t& point4,
const point_t& point5,
const point_t& point6,
const point_t& point7,
const point_t& point8);
const char* getName(void) const;
void write(rt_wdb* wdbp);
private:
std::string name; //The name will be the element number from .k file
rt_arb_internal arb_internal;
};
then a class Solid
class Solid {
public:
void setName(const char* value);
void addArb( struct Arb);
private:
std::string name; // the name will be the part name from .k file
std::vector<Arb> arbs; // fake Bag of arbs
};
Then finally a Geomtry class :
class Geomtry{
public:
//necessary functions
private:
Solid solid;
Bot bot;
};
what do you think?
Louis Googl (Jul 01 2024 at 16:36):I created a draft PR so maybe you can see better the classes that I implemented Solid and Arb. I hope the code is not to dirty to understand :octopus: . My plan is to merge Bot and Solid classes in the Geomtry class. if you agree on the approach I will prepare a better code. the Region list will contain the Geomtry class insted of bot and solid as I did now, this code is just for demonstartion purposes.
Daniel Rossberg (Jul 02 2024 at 16:32):I wouldn't separate Solid and Arb. We don't separate Bot and Triangles either. Create an Arbs class which behaves similar to Bot - with an addArb() method.
Keep in mind that the Bot class refers explicitly to the bot BRL-CAD object. Arbs should do this too. The stuff in k_parser does not. It's BRL-CAD agnostic.
Louis Googl (Jul 02 2024 at 17:18):So I don't need a Solid class?
The Arbs class will refer to the BRL-CAD object through rt_arb_internal or there is another way?
Louis Googl (Jul 02 2024 at 17:19):I will start with it tomorrow, today I am having a very nasty headache :pensive:
Daniel Rossberg (Jul 02 2024 at 17:37):Louis Googl said:
So I don't need a Solid class?
The Arbs class will refer to the BRL-CAD object through rt_arb_internal or there is another way?
There are other ways, e.g. maintaining an intermediate list of the points std::vector<double[3][8]>, but std::vector<rt_arb_internal> is more straight forward, or?
Daniel Rossberg (Jul 02 2024 at 17:38):Louis Googl said:
I will start with it tomorrow, today I am having a very nasty headache :pensive:
Get well soon!
Louis Googl (Jul 03 2024 at 16:24):I updated the PR with the Arbs class, it's still missy in Region_list I will make it better when we decide on the Geomtry class. I didn't find that writing a getArb() method is necessary, but getArbs() is the one we need for writing the arbs in the data base inside regions.creat() . let me know what you think.
Louis Googl (Jul 03 2024 at 16:26):if you think Arbs is fine, I can creat a Geomtry class with Bot and Arbs as members and the type variable, then modify the logic in k-g and region_list
Louis Googl (Jul 05 2024 at 14:49):I have implemented the Geomtry class in the way I imagned it, mayb it's more clear now. Please let me know what you think. I also created a pull reqest for case insensitve keywords
Louis Googl (Jul 05 2024 at 14:53):I was also checking out some other examples from LS-DYNA I found in the sloshing example two commands that we didn't implement, *MESH_SURFACE_NODE and *MESH_SURFACE_ELEMENT, but I couldn't fine anything about these two commands in the documentations.
mesh_fluid.k
image.png
image.png
Sean (Jul 11 2024 at 17:48):@Louis Googl this is all outstanding progress -- are you able to handle this one yet? https://www.dynaexamples.com/implicit/yaris-static-suspension-system-loading/zip-for-download.zip
Louis Googl (Jul 12 2024 at 12:14):Hi @Sean actually the file doesn't convert totally, I can convert the ground but not the car yet, still there is some problems. I am working on the problems I think I will be able to convert it today.
Louis Googl (Jul 12 2024 at 12:39):image.png
I was faster than I expected :rolling_on_the_floor_laughing: , the car is converting but not perfectly. I still need to handle *ElEMENT_BEAM, *ELEMENT_DISCRETE , *ELEMENT_MASS, *SECTION_BEAM and *SECTION_DISCRETE.
Louis Googl (Jul 12 2024 at 12:42):additionally I need to color it as you can see it's difficult to recognize the parts
Sean (Jul 12 2024 at 17:30):That's still awesome! Impressive progress. There are a whole host of sample .k files on that site that will be good test cases. Some are very simple, some very complex.
Louis Googl (Jul 13 2024 at 22:59):Thank you. I think I need to modify the approach instead of using examples and checking if something is wrong I will go through the documentation and implement all kinds of elements and sections.
Louis Googl (Jul 13 2024 at 23:02):One issue that is still not clear to me is the command *INCLUDED_TRANSFORM, this command causes a shift in elements IDs, a coordinate transformation and scaling, but it's not obvious from the documentation how that happens
Louis Googl (Jul 13 2024 at 23:02):I will read more and see if I can figure it out
Sean (Jul 14 2024 at 05:19):It's of course good to revisit the docs, but I also would check examples from time to time since that's the practical validation that will actually matter. We've implemented many many converters over the years and I can tell you there have been many times when the docs say the format should have one thing, but actual files have something else entirely. It's good to check both.
This is still pretty early stages, so not surprising that there are still elements, sections, and transforms to consider. I was surprised you got anywhere near as far as you did with the car since that was a non-trivial test case.
That said, there are much much simpler test cases on that same site that demonstrate specific concepts. They might actually help with understanding what the docs describe, or help understand how elements are encoded, where data is stored, etc.
Sean (Jul 14 2024 at 05:22):For example, https://www.dynaexamples.com/introduction and https://www.dynaexamples.com/introduction/examples-manual and https://www.dynaexamples.com/implicit/basic-examples and https://www.dynaexamples.com/show-cases
Sean (Jul 14 2024 at 05:27):Nice overview of all the keywords on this site: https://2021.help.altair.com/2021.2/hwsolvers/rad/topics/solvers/rad/ls_dyna_keywords_r.htm
Sean (Jul 14 2024 at 05:30):ah, interesting, INCLUDE_TRANSFORM is like a #include but lets you change that file dynamically (e.g., to map it to different location, or different units, or different ID ranges, etc)
Sean (Jul 14 2024 at 05:33):(source: https://ftp.lstc.com/anonymous/outgoing/jday/manuals/ls-dyna_971_manual_k_rev1.pdf)
Daniel Rossberg (Jul 14 2024 at 14:36):Regarding the primitives' names: How about having std::vector<std::string> Bot::write(rt_wdb* wdbp) and std::vector<std::string> Arbs::write(rt_wdb* wdbp)? Then, you could write
std::vector<std::string> Geometry::write(rt_wdb* wdbp)
{
std::vector<std::string> ret = m_bot.write(wdbp);
std::vector<std::string> arbNames = m_arbs.write(wdbp);
ret.insert(ret.end(), arbNames.begin(), arbNames.end());
return ret;
}
The return of this had to be used in RegionList::create(). If doing so, there would be no need for a geometry type.
Daniel Rossberg (Jul 14 2024 at 14:38):The name of the bot is <base-name>.bot. The names of the arbs can be determined on write as <base-name>.<index>.arb, or?
Louis Googl (Jul 14 2024 at 16:59):@Daniel Rossberg you are right, I don't know why I got stuck on trying to name the objects immediatly when the Geomtry class is named. I didn't consider to name the bot inside the write function of m_bot and m_arbs, I will update the pull request. Thank you for the advice.
Louis Googl (Jul 14 2024 at 17:05):@Sean True, a mixed approach between examples and documentation is the way to go. I will check out the soruces you sent me. Thanks for the support.
Louis Googl (Jul 14 2024 at 17:33):@Daniel Rossberg the only thing that is missing is we need Part_Name.arbs equivelent to Part_Name.bot, because in the Bot we don't name the single triangle, but in the fake bag of arbs we have names for the individual arb, I will find a work around
Louis Googl (Jul 14 2024 at 20:31):I updated the PR, hopfully it solves the naming problems. let me know what you think
Daniel Rossberg (Jul 15 2024 at 19:22):Louis Googl said:
Daniel Rossberg the only thing that is missing is we need Part_Name.arbs equivelent to Part_Name.bot, because in the Bot we don't name the single triangle, but in the fake bag of arbs we have names for the individual arb, I will find a work around
I saw, you found it :grinning_face_with_smiling_eyes:
Louis Googl (Jul 15 2024 at 19:31):I am implementing *PART_CONTACT, this increases the number of parameters related to the Part, but they are not geometrical properties so I would just need to add a case partLineRead 2 . Does it need a comment?
image.png
image.png
Daniel Rossberg (Jul 21 2024 at 14:41):Yes, like "some part types like CONTACT have an additional line of non-geomatric data" (only a suggestion).
Louis Googl (Jul 21 2024 at 14:43):I am claning up the Geometry pull request I will let you know when I update the PR.
Louis Googl (Jul 21 2024 at 14:47):I asked you some questions about the constructors on the github reveiw, did you have time to see them?
Daniel Rossberg (Jul 21 2024 at 14:48):Do you mean the one, I've answered some minutes ago?
Louis Googl (Jul 21 2024 at 14:49):yes I jsut saw it, needed to refresh the page :grinning_face_with_smiling_eyes:
Daniel Rossberg (Jul 21 2024 at 14:52):Added something regarding the Geometry class: The standard ones should do it.
Louis Googl (Jul 21 2024 at 20:35):I cleaned up the PR, but still I didn't handle the other types of arb. I was searching in the code I didn't find something similar to ID_ARB8, like ID_ARB7 or ID_ARB6...etc to be used with wdb_export(). I will keep on it tommorrow.
Sean (Jul 21 2024 at 20:35):Arb4 through Arb7 are all stored as Arb8, just encoded as duplicate vertices in a specific way.
Sean (Jul 21 2024 at 20:37): * -------+-------------------------
* Solid | Redundant storage
* Type | of some of the vertices
* -------+-------------------------
* ARB4 | 3=0, 5=6=7=4
* ARB5 | 5=6=7=4
* ARB6 | 5=4, 7=6
* ARB7 | 7=4
* ARB8 |
* -------+-------------------------
Calling rt_arb_get_cgtype(&type, ...) returns 4 through 8 in'type' to indicate which it is.
Louis Googl (Jul 21 2024 at 20:39):okay that's great, so I just need to dublicate the verticies in the correct way.
Louis Googl (Jul 21 2024 at 20:41):I saw something similar in arb8.cpp
image.png
but it wasn't about vertices, it's about faces and edges
Sean (Jul 21 2024 at 20:42):Yes, there are a handful of tables like that, all because of the overloaded array encoding.
Sean (Jul 21 2024 at 20:42):In fact, I posted the wrong table originally, just updated with the right duplications.
Sean (Jul 21 2024 at 20:43):rt_arb_std_type() is another function that returns the type instead of taking it as a param, and takes an rt_db_internal instead of an internal.
Louis Googl (Jul 21 2024 at 20:46):Sean said:
the duplication is clear, but what does it mean 3=0 for arb4 ?
Sean (Jul 21 2024 at 20:48):So an arb4 has 4 vertices, that means it's duplicated as follows:
[0]=..; [1]=..; [2]=..; [3]=[0]; [4]=..; [5]=[4]; [6]=[4]; [7]=[4];
Sean (Jul 21 2024 at 20:48):so if I were to print it, I'd print [0], [1], [2], [4].
Louis Googl (Jul 21 2024 at 20:49):programing in matlab for 3 years, I forgot that 0 can be an index :melting_face:
Sean (Jul 21 2024 at 20:50):They're some deeper reason why they're not simply the first 4 for arb4, but that's what it is.
Sean (Jul 21 2024 at 20:52):arb4 is 01204444
arb5 is 01234444
arb6 is 01234466
arb7 is 01234564
arb8 is 01234567
Louis Googl (Jul 21 2024 at 20:53):what is the reason?
Sean (Jul 21 2024 at 20:58):Honestly, I don't remember, I just remember that there was some deep reason from way back in a time when it mattered.
Almost certainly doesn't matter to that extent any longer, but I have a vague recollection that it was multiple reasons. Something to do with being able to replicate the face, edge, and vertex editing logic so that there's not 5 case blocks everywhere. I think there was also some very low-level disk optimization too (probably not as important any more). Also think there was some compatibility with GIFT (another geometry system) which ARB8 was based on.
Sean (Jul 21 2024 at 20:58):Would have to dig through code and old docs to remind ourselves for sure.
Louis Googl (Jul 21 2024 at 21:01):the code is huge, there are a lot of things to learn, also it is intersting how old solutions affects what we do now.
Daniel Rossberg (Jul 22 2024 at 16:46):You can use MOOSE as reference, e.g. Arb8.cpp.
Louis Googl (Jul 22 2024 at 19:14):I updated the PR, either AddArb is correct or it's very wrong :grimacing:, let me know what you think.
Louis Googl (Jul 22 2024 at 19:17):I was reading in the documentaion about elements with higher number of nodes
do we need to write all the nodes in the .g file or just the nodes that are sufficient to get the geometry?
image.png
image.png
Daniel Rossberg (Jul 22 2024 at 19:22):Ideally, the ones that are sufficient to get the geometry only.
Daniel Rossberg (Jul 24 2024 at 17:26):@Louis Googl: I'm just reviewing your "Geometry class" PR, and I wonder, why Arbs::addArb() has the arbName parameter. It make the whole thing a more complicated. Without it, you could write in k-g.cpp
else if (kData.elements[*itr].nodes.size() == 8)
AddArb(kData.elements[*itr].nodes[0],
kData.elements[*itr].nodes[1],
kData.elements[*itr].nodes[2],
kData.elements[*itr].nodes[3],
kData.elements[*itr].nodes[4],
kData.elements[*itr].nodes[5],
kData.elements[*itr].nodes[6],
kData.elements[*itr].nodes[7],
kData, geometry);
and in Arbs declare arbs as std::vector<rt_arb_internal> write
std::vector<std::string> Arbs::write
(
rt_wdb* wdbp
){
std::vector<std::string> ret;
for (size_t i = 0; i < arbs.size(); ++i) {
std::string arbName = name;
arbName += ".";
arbName += std::to_string(i);
arbName += ".arb";
ret.push_back(arbName);
you are right the code you wrote is nicer, but I added the arbName because the elements number in LS-DYNA doesn't start always from 1 and go on ascending order. the thing is I wanted to preserve the element number as is written in the .k file. if you find this unneccessary I can modify the code. what do you think?
image.png
Louis Googl (Jul 24 2024 at 18:59):I am also working on a new PR related to unhandeled sections, elements and parts, but it relies on the Geometry class, so I will submit it after we close the Geometry PR.
Louis Googl (Jul 26 2024 at 15:52):regarding the ELEMENT_BEAM do we want to draw it as a line or we take the section and extrude it? in LS-PrePost they draw it as a line. the beams in the following image have an I section (section 1 in the second image) but they are represented as a line.
image.png
image.png
Louis Googl (Jul 26 2024 at 16:02):another thing I am working on is the distinction between different commands and a command with options
for example *PART and *PART_ADAPTIVE_FAILURE are two different commands, but *PART and *PART_CONTACT are the same *PART command with the option CONTACT, also because the order of the options defines what the following cards (lines) contains, so I think we are going to need a vector of strings to hold the options and we need to combine the logic to check partLinesRead and the options vector to know what card we are reading. This will not be necessary for all the options as most of them aren't related to the geometry.
image.png
image.png
Louis Googl (Jul 26 2024 at 16:11):another issue is that an option can override properties that are defined in other places, for example if we have *SECTION_BEAM with a certain thickness and then *ELEMENT_BEAM with the option THICKNESS i.e *ELEMENT_BEAM_THICKNESS the latter command overrides the thickness defined in the former command. I am trying to find a way to protect the information provided by the superiour command so it doesn't change if the *SECTION_BEAM comes after *ELEMENT_BEAM_THICKNESS
Louis Googl (Jul 27 2024 at 16:10):I submitted a PR to handle the element options, similarly this will be the way to handle the section's options. and eventually if we want to handle all elements we will need this code or a similar one. @Daniel Rossberg let me know what you think :salute:.
Daniel Rossberg (Jul 28 2024 at 15:08):Louis Googl said:
regarding the ELEMENT_BEAM do we want to draw it as a line or we take the section and extrude it? in LS-PrePost they draw it as a line. the beams in the following image have an I section (section 1 in the second image) but they are represented as a line.
image.png
image.png
For BRL-CAD, we need all elements as solids. I.e., they should have the real beam shape, if feasible. If that's too complicated or the real shape isn't well defined, a cuboid with corresponding line-of-sight value would be possible.
Daniel Rossberg (Jul 28 2024 at 15:19):Louis Googl said:
another thing I am working on is the distinction between different commands and a command with options
for example *PART and *PART_ADAPTIVE_FAILURE are two different commands, but *PART and *PART_CONTACT are the same *PART command with the option CONTACT, also because the order of the options defines what the following cards (lines) contains, so I think we are going to need a vector of strings to hold the options and we need to combine the logic to check partLinesRead and the options vector to know what card we are reading. This will not be necessary for all the options as most of them aren't related to the geometry.
image.png
image.png
In the converter, the distinction is done with the KState enumeration. This addresses the real different stuff. E.g., PART and PART_INERTIA are in fact the same, PART_ADAPTIVE_FAILURE is something different.
Regarding the options, I'll review your proposal in the PR.
Louis Googl (Jul 28 2024 at 15:25):Daniel Rossberg said:
For BRL-CAD, we need all elements as solids. I.e., they should have the real beam shape, if feasible. If that's too complicated or the real shape isn't well defined, a cuboid with corresponding line-of-sight value would be possible.
is there some example code I can look at?.
for a beam that have a T section we can devided to two arbs? or is there a methode for extrusion from the section?
image.png
Daniel Rossberg (Jul 28 2024 at 15:47):Hmm, theoretically, we have the extrude primitive, which extrudes a 2D sketch along a line. Using arbs would be possible too (overlaps wouldn't matter).
Daniel Rossberg (Jul 28 2024 at 15:55):Regarding the options: Do we have a kind of stack there? E.g., for every option a global, section and element value? WE could think about crating an option object, which reacts on the enter section, enter element, exit element, and exit section events. (I don't know, if we can really say when we "exit" something, maybe we can see the "enter"s only.)
Louis Googl (Jul 28 2024 at 16:24):the option card or line follows directly under the command say we have Element_Beam_Section card3 will be there and card2 wouldn't. this is the way to know that you are exiting an element, number of lines is equal to the required card pluse the number of options.
image.png
Daniel Rossberg (Jul 28 2024 at 17:29):Louis Googl said:
another issue is that an option can override properties that are defined in other places, for example if we have *SECTION_BEAM with a certain thickness and then *ELEMENT_BEAM with the option THICKNESS i.e *ELEMENT_BEAM_THICKNESS the latter command overrides the thickness defined in the former command. I am trying to find a way to protect the information provided by the superiour command so it doesn't change if the *SECTION_BEAM comes after *ELEMENT_BEAM_THICKNESS
I understood that *SECTION_BEAM and *ELEMENT_BEAM can be in any order anywhere in the data. The link will be created when parsing KData via the IDs. I.e., the thicknesses have to be stored in the data and evaluated when parsing it.
Louis Googl (Jul 28 2024 at 17:59):yes, now I understand what you meant. exactly the the ID is the link. but after storing the thickness from ELMENT_BEAM_THICKNESS it needs to be protected from change, and if it's taken from SECTION_BEAM it should be modifiable.
Daniel Rossberg (Jul 28 2024 at 18:41):You need a kind of std::map<std::string, std::string> or std::map<std::string, double> for the options:
thickness := default
if SECTION.options[THICKNESS] then
thickness := SECTION.options[THICKNESS]
if ELEMENT.options[THICKNESS] then
thickness := ELEMENT.options[THICKNESS]
(That's pseudo-code, of course.)
Sean (Jul 28 2024 at 23:03):Examples of sketch+extrude are at https://brlcad.org/wiki/Sketch and https://brlcad.org/wiki/Extrude
Louis Googl (Jul 31 2024 at 15:50):I updated the PR, I did it for the ELEMENT_BEAM options. I have used an options counter to indecate which card we are dealing with and a switch statment to handle all possible options, and I think it's better than using elementLinesRead. Let me know what you think @Daniel Rossberg
Daniel Rossberg (Aug 02 2024 at 16:34):I don't think that it makes sense to distinct between elementOptions, sectionOptions, elementBeamOptions in k_parser.cpp. Every set of options belongs to the current state there. The merging of e.g. elements and sections has to be done when the KData structure is evaluated in k-g.cpp.
Louis Googl (Aug 02 2024 at 18:41):yes I agree. I will creat a single enum to include all kinds of options.
Louis Googl (Aug 02 2024 at 18:46):about the element and section merging I think it's better if we expand Kelement to include more information. because usually the Part has a section id which get inhereted by the elements that belong to that Part, but an element with the option Section overrides these information only for that element. I am thinking about it, I will update the code and maybe it will be clearer
Louis Googl (Aug 03 2024 at 10:24):it's a littile bit more complicated than I imagened, say that we have a shell element number 2000 in Part number 1, associated to section number 2 and another shell element 3000 that belongs also to Part 1 and has the section option activated, then element 3000 will have different thickness than element 2000. but on the brlcad side we can set the thickness to the entire bag of triangles do we want to creat a different BoT everytime we have an element with different thickness? or Ignore this option in shell elements?
Louis Googl (Aug 03 2024 at 10:25):also we are already ignoring indvidual thicknesses at the nodes, because we are taking the avrage
image.png
Louis Googl (Aug 03 2024 at 11:55):I updated the PR, I don't know if it's a good idea to stuff all the option card values in a vector then interpret them later in k-g.cpp. what do you think?
Louis Googl (Aug 04 2024 at 09:05):I also have been trying to implement the coloring for the regions for a while, but I didn't find random coloring in MOOSE. I tried also to use bu_color_rand() but I didn't find a way to convert bu_color to rgb. it can be done as in the old k-g converter though
image.png
Daniel Rossberg (Aug 04 2024 at 19:16):Louis Googl said:
I updated the PR, I don't know if it's a good idea to stuff all the option card values in a vector then interpret them later in k-g.cpp. what do you think?
I think that this is the only possibility. We need the complete information from all cards to generate the BRL-CAD geometry.
Regarding BoTs with varying thickness: A triangle can have only one thickness, but you can set an individual thickness for every triangle in a BoT.
Daniel Rossberg (Aug 04 2024 at 19:23):Louis Googl said:
I also have been trying to implement the coloring for the regions for a while, but I didn't find random coloring in MOOSE. I tried also to use bu_color_rand() but I didn't find a way to convert bu_color to rgb. it can be done as in the old k-g converter though
image.png
bu_color codes the values as floats between 0 and 1. You can use bu_color_to_rgb_chars() to get them as ints between 0 and 255.
Louis Googl (Aug 05 2024 at 19:01):If only I have read 10 more lines in color.h :melting_face:
Louis Googl (Aug 05 2024 at 19:19):I remember that you merged this pull request PR but I can't find the functions read_line_node_long() read_line_node_i10(). I also tried to check subsequent pull requests I have not delete them. what do you think happened?
Louis Googl (Aug 05 2024 at 20:01):image.png
I don't think we can do something like this on BRL-CAD side. no?
Louis Googl (Aug 05 2024 at 20:14):I updated the PR with element Pulley and I submitted a PR for the random region color.
Louis Googl (Aug 05 2024 at 20:16):let me know what you think about the
struct KElementPulley
we will have to creat another new Kelement also for *ELEMENT_BEARING
image.png
Louis Googl (Aug 05 2024 at 20:17):the examples server is down :octopus:
image.png
Sean (Aug 05 2024 at 21:25):Louis Googl said:
image.png
I don't think we can do something like this on BRL-CAD side. no?
If there are parameters that describe the thread/yarn/cable radius, it could probably be encoded as a pipe primitive.
Louis Googl (Aug 06 2024 at 07:07):I meant pulling out of the yarn. This element will be a point at t=0 until there is a force to pull on the yarn
Daniel Rossberg (Aug 06 2024 at 18:57):Louis Googl said:
I remember that you merged this pull request PR but I can't find the functions read_line_node_long() read_line_node_i10(). I also tried to check subsequent pull requests I have not delete them. what do you think happened?
Ups, it looks like your PR #147 removed them.
Sean (Aug 06 2024 at 22:22):Louis Googl said:
I meant pulling out of the yarn. This element will be a point at t=0 until there is a force to pull on the yarn
Understood -- the point was that the state at t=whatever can probably be "somewhat easily" described geometrically as a pipe primitive. At t=0, there are some quantity of pipe bends implied in an increasing count depending on the width of the wire and width of the spool. As it's pulled out, each t=XX would geometrically reduce the number of bends/rotations.
That's not to say that there's currently a function to do that, but that it's not terribly complicated to think about what would be needed for a simple/naive implementation (sans and sort of compression).
Louis Googl (Aug 06 2024 at 22:56):That would be nice to implement
Louis Googl (Aug 07 2024 at 15:30):Daniel Rossberg said:
Louis Googl said:
I remember that you merged this pull request PR but I can't find the functions read_line_node_long() read_line_node_i10(). I also tried to check subsequent pull requests I have not delete them. what do you think happened?
Ups, it looks like your PR #147 removed them.
I will include them in the next pull request.
Louis Googl (Aug 07 2024 at 20:05):I added Element_Beam_Source and Element_Bearing, @Daniel Rossberg let me know if you have any objections .
Louis Googl (Aug 07 2024 at 20:06):I am also working on the corresponding sections and then I think I will move from the parser side to BRL-CAD. Or do you think I should finish all the elements on the parsing side first?
Louis Googl (Aug 08 2024 at 16:32):Louis Googl said:
I added Element_Beam_Source and Element_Bearing, Daniel Rossberg let me know if you have any objections .
Don't worry about elementLinesRead, I am going to replace all LinesRead variables with one variable cardCounter
Louis Googl (Aug 08 2024 at 16:34):and maybe eventually we replace the cardCounter and optionCounter with a lineCounter variable, I am trying to see if it's possible to generalize.
Daniel Rossberg (Aug 08 2024 at 17:08):Louis Googl said:
I added Element_Beam_Source and Element_Bearing, Daniel Rossberg let me know if you have any objections .
This is probably the ways how this has to be done.
Daniel Rossberg (Aug 08 2024 at 17:12):Louis Googl said:
I am also working on the corresponding sections and then I think I will move from the parser side to BRL-CAD. Or do you think I should finish all the elements on the parsing side first?
Well, your GSoC time is approaching its end. There are only 2 weeks left.
...
However, maybe you can have a look at the g-k side and make a proposal or proof of concept how this could be done.
Louis Googl (Aug 08 2024 at 17:21):yes, I know that the end time is getting closer. I will propably keep working on the project after the end of GSOC.
Louis Googl (Aug 08 2024 at 17:23):I don't think I will be able to finish the element Bearing but at least I will prepare the section extrusion for the beam element.
Louis Googl (Aug 09 2024 at 15:24):image.png
these people at LS-DYNA spend there days inventing ways to change the order of the cards in .k files :laughing:
Daniel Rossberg (Aug 09 2024 at 16:23):Their data format is closely connected to the features: If someone introduces a new feature, which needs to store some data, they hack it among the others branching with wild flags.
Louis Googl (Aug 09 2024 at 16:28):it is a very versatile software. I tested for the first 7 charachtes like this
image.png
Louis Googl (Aug 13 2024 at 19:52):I'm currently workin on an implemtation of the beam elment with cross section type 1 which is a circular tube. The plan is to implemente it as a pipe primative
Daniel Rossberg (Aug 14 2024 at 16:25):"cross section type 1": Is this the I-shape?
Louis Googl (Aug 14 2024 at 16:47):No this is the Tubular
image.png
Louis Googl (Aug 14 2024 at 16:49):image.png
for the resultant beam type 1 is the I-shape.
Louis Googl (Aug 14 2024 at 16:51):how do you like my addBeam() function :grinning_face_with_smiling_eyes:
image.png
Louis Googl (Aug 15 2024 at 11:06):this is how it looks like using the Pipe premative, this is a part of the Yaris car model
image.png
image.png
Louis Googl (Aug 15 2024 at 11:09):it's not perfect though. considering each element by itself will only provide the C0 continuity. This is because the bend radious is not provided by the .k file.
image.png
Louis Googl (Aug 15 2024 at 11:09):what do you think?
Daniel Rossberg (Aug 15 2024 at 16:00):Hmm, some thoughts:
Louis Googl (Aug 15 2024 at 16:17):1- I put a constant value for bending radious, because I read in the documentation that bending radious can't be zero.
2- I was thinking about this, but I though if I put all the beam elements in 1 pipe premative they are going to be connected together using the facke bending radious I used. I will check the link you provided and modify.
3- yes I agree, I called it beam because I was thinking to put all beams inside it, but maybe it's going to be very messy. let's call this one pipe and maybe in the future we can combine all beam elements in one class
Daniel Rossberg (Aug 16 2024 at 17:18):That the bend radius is "fake" isn't so bad. What is its minimum value? 2 times the outer radius, or the ray-trace will complain?
Louis Googl (Aug 16 2024 at 17:23):image.png
it will depend on the inner and outer diameter
Louis Googl (Aug 16 2024 at 17:35):I should have finished the modifications yesterday but I faced a problem, when I use the wdb_export() on line 77 it works, but the one on line 88 prduces export failure, to me the lines are the same but I coudn't know why it produces this error
image.png
image.png
Louis Googl (Aug 16 2024 at 17:37):the lines are the same because rt_pipe_internal* m_pipe; should be equivelent to rt_pipe_internal* pipe_wdb;
Daniel Rossberg (Aug 16 2024 at 17:40):Why does it depend on the inner diameter too? The most extreme torus would be one with no hole, i.e. the bend radius is two times the pipe or torus radius. See e.g. https://github.com/BRL-CAD/brlcad/blob/main/src/librt/primitives/pipe/pipe.c#L4320
Louis Googl (Aug 16 2024 at 17:44):No you are right. I just guessed that it might be dependent on the inner radious :melting_face:. I will put it as 2 times the external radius.
Daniel Rossberg (Aug 16 2024 at 17:47):Louis Googl said:
the lines are the same because rt_pipe_internal* m_pipe; should be equivelent to rt_pipe_internal* pipe_wdb;
Hmm, I don't have your full code, but in https://github.com/BRL-CAD/brlcad/pull/151 there is //rt_pipe_internal m_pipe;, i.e. without the * pointer declaration.
Louis Googl (Aug 16 2024 at 17:50):I just pushed the code. the comment is old, now it is rt_pipe_internal* m_pipe
Louis Googl (Aug 16 2024 at 17:58):ThreebeamIn1.k
there is this small file if you want to test, the car model taks long time
Daniel Rossberg (Aug 17 2024 at 15:28):Lines 33 and 34 of pipe.cpp
m_pipe->pipe_segs_head.magic = RT_PIPE_INTERNAL_MAGIC;
m_pipe->pipe_count= 0;
look suspicious, especially the first one, with the RT_PIPE_INTERNAL_MAGIC. BU_LIST_INIT does already the right things.
Louis Googl (Aug 19 2024 at 15:57):I think I found it, it is not the suspicious lines. If I check the first element in the list before calling BU_LIST_APPEND_LIST I see the correct information, but when I check it after calling it everything disappers. it seems like BU_LIST_APPEND_LIST is deleating the pointer or freeing it
image.png
Louis Googl (Aug 19 2024 at 18:56):image.png
The wiki is down, do you know what is wrong?
Louis Googl (Aug 19 2024 at 18:57):also I just received an email from GSOC to prepare the final submission. do you have any specifications? or shoud I do a wiki page like last time?
Louis Googl (Aug 19 2024 at 21:04):should I start a new pull request for the sketch and extrude or keep working\adding on the same pull request?
Daniel Rossberg (Aug 20 2024 at 17:10):Louis Googl said:
should I start a new pull request for the sketch and extrude or keep working\adding on the same pull request?
If you think that a pull request is ready for merging, please tell me.
Daniel Rossberg (Aug 20 2024 at 17:10):Louis Googl said:
also I just received an email from GSOC to prepare the final submission. do you have any specifications? or shoud I do a wiki page like last time?
I've no other requirements than last time ... if the wiki is up again.
Louis Googl (Aug 20 2024 at 17:15):I have cleaned up the Pipe class, if you have no objections I think it's ready to be merged.
Louis Googl (Aug 20 2024 at 17:17):I think it's better if I creat a GitHub gist, maybe the wiki will still have some problems. I will share the link with you as soon as it's ready.
Daniel Rossberg (Aug 20 2024 at 18:32):Louis Googl said:
I think it's better if I creat a GitHub gist, maybe the wiki will still have some problems. I will share the link with you as soon as it's ready.
Possible, or a alihaider93.github.io page?
Louis Googl (Aug 21 2024 at 19:00):I fixed the file endings
Louis Googl (Aug 21 2024 at 19:01):also the sketch is going well, I still have to do the extrusion
image.png
Louis Googl (Aug 22 2024 at 12:14):@Daniel Rossberg I am preparing the final report. it's not ready, but the general theme is set, if you have some time please let me know if you think it's fine like this Report
Daniel Rossberg (Aug 23 2024 at 17:10):Looks good :smiling_face:
Louis Googl (Aug 23 2024 at 17:18):Thank you :heart_eyes: . I am still improving it, and I will add the sketch and extrude PR link, after we close the current one.
Louis Googl (Aug 23 2024 at 17:44):I though I fixied the issue with the thrid node yesterday. But I was wrong :sunglasses: . now it's fine.
Daniel Rossberg (Aug 23 2024 at 17:49):Just wondered :thinking:
Louis Googl (Aug 23 2024 at 17:50):because I added a big chunk of code on my local repository, but I didn't push it yet, so the line that I commented yesterday isn't the correct line to solve the problem.
Daniel Rossberg (Aug 23 2024 at 17:52):Next bunch of issues (errors):
[ 79%] Building CXX object src/conv/k-g/CMakeFiles/k-g.dir/k_parser.cpp.o
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp: In function ‘bool parse_k(const char*, KDat
a&)’:
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Bl
anking’ not handled in switch [-Werror=switch]
596 | switch (state) {
| ^
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Di
rect_Matrix_Input’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Di
screte’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Di
screte_Sphere’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ge
neralized_Shell’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ge
neralized_Solid’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_In
ertia’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_In
terpolation_Shell’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_In
terpolation_Solid’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_La
ncing’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ma
ss’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ma
ss_Matrix’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ma
ss_Part’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Pl
otel’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt_Accelerometer’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt_Pretensioner’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt_Retractor’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt_Sensor’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Se
atbealt_Slipring’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Sh
ell_Nurbs_Patch’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Sh
ell_Source_Sink’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_So
lid_Nurbs_Patch’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_So
lid_Peri’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Sp
h’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Tr
im’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Element_Ts
hell’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Be
am_AISC’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Di
screte’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Fp
d’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Po
int_Source’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Po
int_source_Mixture’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Se
atbelt’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_So
lid_Peri’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Sp
h’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:596:24: error: enumeration value ‘Section_Ts
hell’ not handled in switch [-Werror=switch]
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:242:34: error: unused variable ‘cardCounter’
[-Werror=unused-variable]
242 | size_t cardCounter = 0;// this will replace sectionLinesRead elementLinesRead, and
partLinesRead
| ^~~~~~~~~~~
/home/rossberg/Devel/BRL-CAD/brlcad.devel_k-g/src/conv/k-g/k_parser.cpp:247:34: error: unused variable ‘CST’ [-Werro
r=unused-variable]
247 | int CST = 0;
| ^~~
cc1plus: all warnings being treated as errors
Maybe, you can comment out (//) unused flags?
Daniel Rossberg (Aug 23 2024 at 17:53):Do you have a Linux to test it?
Louis Googl (Aug 23 2024 at 17:53):I will comment the unused flags.
Louis Googl (Aug 23 2024 at 17:54):yes I also have a linux machine. but it will take a littile while to setup. I will let you know after I test
Louis Googl (Aug 23 2024 at 19:02):Screenshot-from-2024-08-23-20-59-17.png
small problem with Ubuntu, any advice?
Daniel Rossberg (Aug 24 2024 at 13:03):It was a time ago, when the devel_k-g branch was created. The CMake build got since some fixes and improvements.
However, what can help is
Louis Googl (Aug 26 2024 at 14:22):I don't know if you had some time to check the new PR. I wanted to ask you if it's okay to do the vector math inside the function Sketch::creatSketch() or should I do it inside k-g.cpp?
image.png
Louis Googl (Aug 26 2024 at 14:24):I also didn't put checks on the cross product because I assume a valid .k model will never have colinear nodes n1 n2 n3 because n3 is used to define the cross-section's plain. I am also assuming that the length of these vectors will never by zero.
Louis Googl (Aug 26 2024 at 14:26):I am currently working on the extrude class.
Daniel Rossberg (Aug 26 2024 at 14:53):Before I forget: There is a build error on macOS: https://github.com/BRL-CAD/brlcad/actions/runs/10538897404/job/29201886436
/Users/runner/work/brlcad/brlcad/src/conv/k-g/k_parser.cpp:1169:19: error: variable 'eid' is uninitialized when passed as a const reference argument here [-Werror,-Wuninitialized-const-reference]
data.elements[eid] = element;
^~~
Maybe, you can initialize eid to some default value?
Louis Googl (Aug 26 2024 at 14:54):will fix it. I am still trying to build on ubuntu. I will test everything also there.
Daniel Rossberg (Aug 26 2024 at 14:56):Louis Googl said:
I don't know if you had some time to check the new PR. I wanted to ask you if it's okay to do the vector math inside the function Sketch::creatSketch() or should I do it inside k-g.cpp?
image.png
It's better to do this in the Sketch class, as you did, because this is sketch specific stuff, not k-file specific.
Louis Googl (Aug 26 2024 at 15:28):extrusion is working on a small .k file I wrote.
image.png
Louis Googl (Aug 26 2024 at 15:29):image.png
image.png
we have same issue of C0 continuity, but I don't think a real model will have I beams arranged like that
Daniel Rossberg (Aug 26 2024 at 15:51):I think, we can get over for now. Maybe sometime, someone wants to add a gold edge :wink:
Louis Googl (Aug 26 2024 at 16:05):what is a gold edge? :grinning_face_with_smiling_eyes:
Sean (Aug 26 2024 at 16:23):Louis Googl said:
I think I found it, it is not the suspicious lines. If I check the first element in the list before calling BU_LIST_APPEND_LIST I see the correct information, but when I check it after calling it everything disappers. it seems like BU_LIST_APPEND_LIST is deleating the pointer or freeing it
image.png
BU_LIST_APPEND_LIST requires there to be a head pointer, which it iterates around until it gets back to the start. If you initialize without one, you're going to get list corruption which will be behavior like you saw.
Sean (Aug 26 2024 at 16:24):Louis Googl said:
image.png
The wiki is down, do you know what is wrong?
I'm working on it. The server started doing some major upgrades which pulled the rug out from under php's modules and required a major php upgrade. That then was incompatible with mediawiki.
Sean (Aug 26 2024 at 16:25):General practice for adding pipe lists would be something like this:
pipe_ip->pipe_magic = RT_PIPE_INTERNAL_MAGIC;
BU_LIST_INIT(&pipe_ip->pipe_segs_head);
for (int i = 0; i < 2; i++) {
BU_ALLOC(pipe_pp, struct wdb_pipe_pnt);
pipe_pp->l.magic = WDB_PIPESEG_MAGIC;
VSETALL(pipe_pp->pp_coord, i);
pipe_pp->pp_od = 1;
pipe_pp->pp_id = 0.1 * pipe_pp->pp_od;
pipe_pp->pp_bendradius = pipe_pp->pp_od;
BU_LIST_INSERT(&pipe_ip->pipe_segs_head, &pipe_pp->l);
}
Louis Googl said:
what is a gold edge? :grinning_face_with_smiling_eyes:
It's a decoration, e.g. for dishes: https://www.ebay.com/itm/304972582544
I looks good, but isn't usually functional.
Louis Googl (Aug 26 2024 at 17:48):Beauty will save the world :laughing:
Louis Googl (Aug 26 2024 at 17:53):Sean said:
Louis Googl said:
image.png
The wiki is down, do you know what is wrong?I'm working on it. The server started doing some major upgrades which pulled the rug out from under php's modules and required a major php upgrade. That then was incompatible with mediawiki.
I added the link to my daily blog on the wiki to the GSoC report, would it be a problem if it's not working by the end of the project? The final report is on github no problem with that.
Louis Googl (Aug 26 2024 at 20:31):@Daniel Rossberg I did some modifications. let me know what you think about the PR
Louis Googl (Aug 28 2024 at 21:07):Guess how many tries does a civil engineer needs to plot a regular Hexagon? :joy:
image.png
image.png
image.png
Daniel Rossberg (Aug 29 2024 at 07:06):Only the result matters :wink:
Louis Googl (Aug 29 2024 at 13:39):In this case is it okay to creat two sketches and extrude them? one for the inner rectangle and one for the outer
image.png
Louis Googl (Aug 29 2024 at 14:12):No need it can be done with one sketch
image.png
Sean (Aug 31 2024 at 04:48):Louis Googl said:
No need it can be done with one sketch
image.png
I was going to say, you can but don't need to. The sketch primitive uses parity on interior loops so you could even add another interior, then subtract something from it, and so on. It's even pretty graceful on crossings, but not recommended as some cases are ill-defined. For simple boxes in boxes, though, that's definitely the way to go.
Louis Googl (Aug 31 2024 at 07:37):I had the idea that a sketch might accept only one closed shape, but then I tried and it worked.
Louis Googl (Sep 10 2024 at 22:34):Finally I finished all the sections, it took some time because I had to go to a conference. @Daniel Rossberg it would be nice if you have some time to check the pull request, I think it's ready for closing.
image.png
Daniel Rossberg (Sep 11 2024 at 07:21):Very nice.
It's ready for accepting/merging, I hope :wink:
Louis Googl (Sep 11 2024 at 07:47):I hope to :grinning_face_with_smiling_eyes:
Daniel Rossberg (Oct 20 2024 at 21:28):I did some stylistic tweaks and created a pull request for the main branch: https://github.com/BRL-CAD/brlcad/pull/163
Louis Googl (Oct 21 2024 at 06:26):That's great. I will check it out. How the turning tables :rolling_on_the_floor_laughing:
Louis Googl (Oct 21 2024 at 06:29):Joking :grinning_face_with_smiling_eyes: . I'm uploading my thesis in 8 days, after that I will continue working on the development branch
Louis Googl (Oct 29 2024 at 14:51):@Daniel Rossberg I checked the changes, I have no objections.
Daniel Rossberg (Oct 30 2024 at 08:02):@Louis Googl, best wishes for your PhD thesis!
@Sean, @starseeker: What do you think about PR #163?
Louis Googl (Oct 30 2024 at 08:54):Thank you:heart:
starseeker (Oct 30 2024 at 18:38):Very nice - I went ahead and merged. Looks like the regression failure was due to some of the files somehow being hard-set to one particular line ending style - I think I fixed that.
Daniel Rossberg (Oct 31 2024 at 08:04):@starseeker, thanks for looking at it. It surprises me that such a line ending mismatch is possible. I thought, the version control system takes care of it. I may need to pay more attention to it.
Last updated: Nov 15 2024 at 00:49 UTC