Trouble reading Optistruct input file in free format
Hi all,
I've created a Matlab file to translate nodes, coordinates, beam elements and beam radii from an external .xml file to an Optistruct .fem input file. I've written the bulk data following the free format, i.e. delimiting the fields with commas instead of writing blocks with a constant 8 characters since that's a hassle. However, when trying to import the file into Hypermesh with the OS reader, the following error shows up:
Error: Invalid value in integer field (-50.00) on line 5, file C:/Users/.../Desktop/thicklattice_from_matlab.fem
Resolution: Quitting..
Summary:Feinput finished with 1 errors and 0 warnings.
This would mean that OS still expects the fixed format, doesn't it? Is there a setting or keyword that has to be set in order for OS to read it as free format?
Edit: Ok I found it, it was a missing empty field after the node ID. I might have further questions coming up though.
Answers
-
Hi again, I've progressed somewhat with the task. However, I still encounter a few issues for which I don't find the solution at the moment. As you can see in the input file created with Matlab, there are 6 components, beam sections and properties as well as one material and one beam section collector. However, the beam sections, properties and material don't get associated correctly and a number of elements get put into a newly created 'misc' collector upon import in Hypermesh. I suspect the $HMMOVE, $HMDPRP and beam section definitions to be faulty. However, when compared to an exported file from HM after having organised everything (as much as possible), I don't see a big difference. What's the cause of this? Is it the free format vs. fixed format?
<?xml version="1.0" encoding="UTF-8"?>
0 -
You don't need $HMMOVE
If you already define props for beams, hm will create comps automatically
'misc' store beams that hm does not find their prop
0 -
Well, if I don't use $HMMOVE, the elements just get all thrown in the misc1 component which is not what I want. They need to be organised by component, each component needs the right property and each property needs the right beam section assigned to it. But what's the error in my input file since it's not imported this way? Apparently, some elements are moved to the wrong collector and some aren't moved at all. Is there a line limit for $HMMOVE?
Also, what does $HMDPRP do exactly? The description is very short and does not give much information and it does not seem to work the way I think it might since it makes no difference in my input file.
<?xml version="1.0" encoding="UTF-8"?>
0 -
As i know, hm comments are not neccessary. Input deck could be from many sources don't have hm comments.
Check your import options, there is one indicating to create comps by props instead of the comments.
0 -
Oh that's it! Great, thank you very very much! That solves one issue at least
/emoticons/default_wink.png' srcset='/emoticons/wink@2x.png 2x' title=';)' width='20' /> I may be back in the next days if I can't figure out the rest.
Another issue, this time a graphical one. Sometimes, when manipulating the properties and/or beam sections, all elements or just part of them vanish. They are still 'displayed' as they are still considered as displayed (for example Choose by displayed gives the correct element number) and I can even select them manually, but they can't easily - or at all - be rendered visible again.
<?xml version="1.0" encoding="UTF-8"?>
0 -
Turn off 'detail representation'
Graphic may have some bugs.
0 -
Hi again. For whom it may concern, I managed to get it to work correctly with all the elements moved to the right components and their properties, materials and beam sections assigned as they should be. For this to work, the import option has to be set to 'By HM comments' and HMMOVE is necessary to move the elements to the correct component, otherwise manual editing is needed.
0 -
Hi again,
I ran into another issue with the import functionality. When I import an input file like the one attached to this post, HM sometimes throws the following warning:
Warning: Dimensions of PBEAML ID 4 are different from Hyperbeam comments, a new Hyperbeam will be created
Warning: Dimensions of PBEAML ID 5 are different from Hyperbeam comments, a new Hyperbeam will be created
Warning: Dimensions of PBEAML ID 5 are different from Hyperbeam comments, a new Hyperbeam will be created
Warning: Dimensions of PBEAML ID 6 are different from Hyperbeam comments, a new Hyperbeam will be created
Summary:Feinput finished with 0 errors and 4 warnings.
This differs of course per model and does not always show up. The odd thing is that all PBEAML entries are defined the exact same way and I did not find a difference to the way HM does it when comparing it to a corrected and exported input file from HM. It's very odd as well that the PBEAML entry with ID 5 gets mentioned twice. Does anyone have any advice?
0
