Temperature Dependent Materials

[Steven DeLessio]

I have a need to import temperature dependent material properties from a bdf file.  The specific file has an MATT1 card that references a blank MAT1 card (all the material properties are temperature dependent).  Although I don't think this is necessarily always the case (meaning there can be a mixed MAT1 entry and other temperature dependent properties referencing the same material). 

Issue 1:  There's no MATT1 class ...easy to fix.  I've attached my take on how you would have created it the best I could.

Issue 2:  The MAT1 object is currently initialized by setting up E, G and nu using 'self.set_E_G_nu()'  which raises a RuntimeError is all of these variables are None.  This is a great idea for a MAT1 card by itself but breaks down for my use case.  I'm not sure the best way to handle this, I've temporarily bypassed the checks using a 'mat_table' attribute in the Material base class, but it really needs to be specified at the BDF or BDF.read_bdf() level.  I've just started getting my head wrapped around the code so I'm not sure what the best way would be to implement this.  I'd like to help out if I could,  I've looked through the code since 0.6.1 and haven't seen anything with MATT1-MATT9 yet.

Just some background, I'm an ANSYS user working at MSFC so I flip back and forth a lot.  The way I translate ANSYS to NASTRAN almost always uses MATT1 cards because ANSYS naturally stores materials by temperature (even when there is only one).  I'm trying to make it so I can seamlessly go between ANSYS to NASTRAN to ANSYS.  I stumbled on your code a while ago and have been using it for the NASTRAN bdf reader (which is awesome!! by the way) rather than creating my own.  

Do you have any plans in the near future at added these cards?  I know there are a lot of things your working on.  Let me know if I can help out.

Thanks,

Steve

[Steven DeLessio]

Simple Idea...change the RuntimeError to a warning and log it, then we just add the MATT1-9 cards.  Unless it breaks other methods you have.

Steve

[Steven Doyle]

Steve,

Hmm...I've had problems trying to deal with MATSx and MATTx cards, which is why they're not supported.  I've got an idea based on some MSC presentation that still needs some fleshing out, but I think it's the right way to go (basically a material can have a strain/temperature/etc. dependence).

Do you have an sample deck?

Steve Doyle

--
You received this message because you are subscribed to the Google Groups "pyNastran dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynastran-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Steven DeLessio]

This is an ANSYS translated file I'm trying to read back into my software (it was written mostly using your print_card method).  I've cut a lot out to reduce the file size but left the material section as is.  

I'm able to workaround the issue with a hack:

I've modified the MAT1 class by replacing the raise error by a logging.warn(msg) and added the MATT1 card, flagging the add_structural_material method to overwrite when it is storing a MATTx works for getting the data (i.e. card) into the BDF object (although you would still want to store both material cards in case there are properties you need from the MAT1, but for my specific situation I don't, so hence, the hack).  Right now all I do is store the integer instead of trying to cross reference the actual table data with the material (for me this is all I need, again...a hack).  

I'm not familiar enough yet with the code to know, but referencing: tables -> material seems similar to nodes -> elements.  Both are integer pointers to other objects.  I guess if you're trying to use the actual properties in other functions this isn't so cut and dry, using dependent properties and storing them are two different things.  All I've done so far is store, read and write them.  

Steve 

[Steven Doyle]

I think I've got something now that makes sense.  The check from the init has been removed. 

Instead, MAT1 cards now have a matt1 and mats1 attribute that defaults to None.  In the cross_reference step, a check for a MATS1 or MATT1 is done.  If either one exists, the code allows having a None value of E/G/nu.  

It's probably not perfect and needs some tests, so take a look and let me know.  Also do you have a sample deck that will run Nastran?  That one is missing nodes/elements/case control deck.

Steve

[Steven DeLessio]

Yeah, let me create a simple one.  I took the nodes and elements out to hide the geometry, I wasn't sure if I could post it.  I'll cook something up to test when I get into work tomorrow.  Sounds like a good approach.

Steve

[Steven DeLessio]

Ok, so I've created a file.  Turns out you do need initial values on your MAT1 card, even if the MATT1 card specifies a table for that same value, for it to work.  So your initial check on the MAT1 card was still valid, in fact needed.  Sorry for jumping the gun on the blank MAT1 card, I never tested it out using NASTRAN.  I guess I would just need the MATT1 cards supported.  

[Steven DeLessio]

imported the file3.bdf without issue using the update.  Thanks for all your help!  

P.S. I've forked your update and gave you commit rights @ sdelessio.googlecode.com/svn/trunk for me to play with.

Thanks,

Steve