R10 release note (tobias): Modify initialization of material directions for solid elements. If there are only zeros for all the 6 values in *INITIAL_STRESS_SOLID, then the values from the other input (e.g. *ELEMENT_SOLID_ORTHO) are kept. ___________________________________________________________ RE: Mapping of orthropic material directions from one shell mesh to another shell mesh In *INCLUDE_STAMPED_PART, there is a variable IORTHO. If IORTHO is set, correct mapping between non-matching meshes is invoked for the directions of orthotropic materials. A list of appropriate values for several materials is given here: IORTHO.EQ.1: materials 23, 122, 157, 234 IORTHO.EQ.3: materials 22, 33, 36, 133, 189, 233, 243 IORTHO.EQ.4: material 59 IORTHO.EQ.6: materials 58, 104, 158 IORTHO.EQ.8: materials 54, 55 IORTHO.EQ.9: material 39 IORTHO.EQ.10: material 82 IORTHO.EQ.13: materials 2, 86, 103 ___________________________________________________________ For the 2nd run, the AOPT values do not matter as the initialization based on AOPT will later be overwritten by the history values in the dynain file. The only thing you should be careful about when using MAT_2 is not to do any rigid body transformations between the runs. Last point: In general, if the information about the history variables listed on the dynasupport.com site is not enough for your needs, contact us, we will look it up for you and add the useful ones to the dynasupport.com site. Stefan -------------------------------------------------------------------- In general it does not matter how the material direction is defined in the original input as this information will be initialized to the history variables at every integration point. Normally the direction sines and cosines are stored with respect to the underlying elemental coordinate system. So once you write out all the history information to the *Initial_stress-card, these information will be available in the next run. The good thing about that, you could basically move your piece in space between the steps, as the orientation information is pinned to the elements. Now when you use MAT_002 in a total Lagrangian setting, the vectors defining the material orientation are defined w.r.t. global coordinate system, so you should not move the part you want to analyze between the different steps. So to make it short: For the computation it should not matter what AOPT you are using, but depending on the AOPT the "visible" orientation may be different when you load the dynain-file into a pre-processor ... but then, you will NOT see what you GET, as the final orientation information is on the history variables and this is what counts. ... So maybe you are more confused now? Best regards, Stefan ----------------------------------------------- I just wanted to give a comment on the possibility to write *ELEMENT_SOLID_ORTHO to the dynain file. Basically this is only for some kind of intermediate pre-/post-processing issues, and should not affect the actual computation. The information about the orientation is normally stored as history variables and should be written to the dynain file (*INITIAL_STRESS_SOLID). Then to MAT_002: You should keep in mind that this material model is formulated in a total Lagrangian setting. Therefore the orientations are initialized with respect to the global coordinate system (Solids). You can find the information on the following history variables (see Theory manual for Mat 2) Solids: #1-9: Deformation gradient #10: l1 #11: m1 #12: n1 #13: l2 #14: m2 #15: n2 l3,m3,n3 are then computed as cross-product. Stefan 7/21/16 Ticket#2016071910000136 ---------------------- Regarding solid elements, the R9.0 release notes include this item from Stefan Hartmann... "Added the possibility to write *ELEMENT_SOLID_ORTHO into dynain file if requested. To activate this add OPTCARD to *INTERFACE_SPRINGBACK and set SLDO=1." jd ___________________________________________________________________________ The notes in the text file  http://ftp.lstc.com/anonymous/outgoing/support/FAQ_kw/composites/composite_preprocessing  attempt to explain LSPP's tools for dealing for composites or orthotropic materials in general.   See also http://ftp.lstc.com/anonymous/outgoing/support/PRESENTATIONS/lsprepostcomposite.pdf . I typically read in the keyword file and use Ident > Element > Mat dir   to view the material directions for element integration points.   Settings is used to change the integration point displayed in the case of shells and tshells.   If you read in both the keyword file and d3plot, I believe the material orientations are updated as you step through the states in the same manner as LS-DYNA updates the directions.    I think the material orientation is seamless if you're restarting from a d3dump file.   If you're using dynain data instead, it may depend on your element type and material model whether the material orientation can possibly be carried over from a prior analysis.   In cases where it's possible, it's accomplished by writing out a sufficient number of history variables to dynain; see NHSV in *interface_springback_lsdyna and those are responsible for initializing the material orientation. Whatever your situation, I strongly advise you run a small test case and compare against baseline analysis to confirm that material orientation carries over. Anders Jernberg has implemented a lot of features in LSPP in support of composites and I've CC'd him in case he wants to interject anything in this discussion.  (Anders, In case you didn't know, Babu works for LSTC on-site at P&G and replaced Vish.) Regards, Jim Day Ticket#2016071910000136 (Please retain this number for continued support.) 07/19/2016 08:25 - Aminjikarai Babu wrote: Hi guys,   1)      Is there any way to visualize material orientations on elements in LSPP? Preferably in d3plot so we can see what the solver is using and also both initially and as they evolve through the solution. I found View > Local Axes, View > A Axis Orientation only, and ElEdit > Direction which can be used with a key file. The 1st two did not help. The last one seems to be a tool to apply directions at the element level (node numbering?) rather than showing what the current ones are based on AOPT definition in the material. Maybe I am missing something. 2)      Restart maps the material orientations too, correct? If there is a need to map orientations from a deformed state in 1st run to initial state of 2nd run, are there any other options?   Thanks.   Regards, Babu