How do I read the property names from MSC Nastran input file?

Hi Edwin,

Thanks very much for the info. I seem to be making more progress with this. I will close the case now, and next time I will be sure to not duplicate a case with the tech support and the user forums. It is probably best to just use one or the other, but not both simultaneously.

My real objective was to automatically load an include file for each part and have patran create a group for each included part. I have a large model assembly with over 55 includes for 55 separate parts. Each include has a bunch of grid and element definitions. Then I also have separate include files with all the materials, element properties, and boundary conditions. I did figure out that the materials and properties did not work with the separate include files with Patran. They work fine for Nastran, but not for Patran. Also, another big problem seems to be that when I converted all the properties from Femap to Patran I chose to use the TUBE2. Well, it looks like Patran also does not like TUBE2 for some reason. If Patran fails to recognize TUBE2, could you please make sure that gets fixed in the next release. Right now my only work around is to convert all the TUBE2 definitions over to TUBE. I like being able to just put the outer radius and thickness, which Nastran will accept. Anyway I am using a pcl script file to loop over each of the include files in my directory and then create a group, and then read the include file while the new group is active, and repeat for all the parts. This will hopefully give me what I want which is a complete FEM for the assembly and all the parts from each include file into their own separate patran group. I wonder if MSC might already have a utility for doing this since surely I cannot be the first person in the last 50 years to be doing this. That is working with a complex assembly model with many complex parts that are each stored in separate include files.

You might wonder why I am going through all the trouble of converting the Femap beam definitions over to PBARL. Well that is because I want to be able to see the actual beam cross sections in patran, and apparently, that is only possible if I use the PBARL or PBEAML. You will notice in the Femap file that I sent you that Femap puts all the beam cross section info into comments that it can read to get the beam cross section geometry for PBAR, PBEAM, PBARL, and PBEAML. If Patran was smart enough to read those Femap comments, then I would have been saved a lot of wasted time. Here at Boeing we use Femap a lot and also Hypermesh.

One of the most useful things would be if there were comments for Patran groups. That way I could put my patran group definitions into the nastran input file. It could be something very simple such as $Patran_Begin_Group, followed by a bunch of grids and elements, then ending with a $Patran_End_Group. Then all the Patran group information could be stored in the Nastran file. This is very important for complex models. I hope that someone over at MSC is always looking for new useful features and improvements for Nastran and for ways to move it beyond the days of IBM punch cards.

Toby Norris
BDS Design Center South
256-721-3459

Hi Edwin,

Thanks very much for the info. I seem to be making more progress with this. I will close the case now, and next time I will be sure to not duplicate a case with the tech support and the user forums. It is probably best to just use one or the other, but not both simultaneously.

My real objective was to automatically load an include file for each part and have patran create a group for each included part. I have a large model assembly with over 55 includes for 55 separate parts. Each include has a bunch of grid and element definitions. Then I also have separate include files with all the materials, element properties, and boundary conditions. I did figure out that the materials and properties did not work with the separate include files with Patran. They work fine for Nastran, but not for Patran. Also, another big problem seems to be that when I converted all the properties from Femap to Patran I chose to use the TUBE2. Well, it looks like Patran also does not like TUBE2 for some reason. If Patran fails to recognize TUBE2, could you please make sure that gets fixed in the next release. Right now my only work around is to convert all the TUBE2 definitions over to TUBE. I like being able to just put the outer radius and thickness, which Nastran will accept. Anyway I am using a pcl script file to loop over each of the include files in my directory and then create a group, and then read the include file while the new group is active, and repeat for all the parts. This will hopefully give me what I want which is a complete FEM for the assembly and all the parts from each include file into their own separate patran group. I wonder if MSC might already have a utility for doing this since surely I cannot be the first person in the last 50 years to be doing this. That is working with a complex assembly model with many complex parts that are each stored in separate include files.

You might wonder why I am going through all the trouble of converting the Femap beam definitions over to PBARL. Well that is because I want to be able to see the actual beam cross sections in patran, and apparently, that is only possible if I use the PBARL or PBEAML. You will notice in the Femap file that I sent you that Femap puts all the beam cross section info into comments that it can read to get the beam cross section geometry for PBAR, PBEAM, PBARL, and PBEAML. If Patran was smart enough to read those Femap comments, then I would have been saved a lot of wasted time. Here at Boeing we use Femap a lot and also Hypermesh.

One of the most useful things would be if there were comments for Patran groups. That way I could put my patran group definitions into the nastran input file. It could be something very simple such as $Patran_Begin_Group, followed by a bunch of grids and elements, then ending with a $Patran_End_Group. Then all the Patran group information could be stored in the Nastran file. This is very important for complex models. I hope that someone over at MSC is always looking for new useful features and improvements for Nastran and for ways to move it beyond the days of IBM punch cards.

Toby Norris
BDS Design Center South
256-721-3459