XANSYS Message: 297 [Go back to message list]
[bookmark on del.icio.us]
No rating yet
Rate item:

Subject: Re: Tet 95 Elements - Slower than Tet 92?
Author: Joe Metrisin
Date: 1999-01-18 14:17:00

I vote for automatically converting 95's to 92's but keep a switch to
disable this for those who may not want it. John Crawford's idea
about changing the degenerate formulation for 95's to match 92's
sounds good but my guess is this would open a big can of worms
on the development side.

Joseph T. Metrisin

Structural Methods
Pratt & Whitney/Unitetd Technologies
M/S: 714-03
P.O. Box 109600
West Palm Beach, FL. 33410-9600

Phone: (561) 796-5967
Fax: (561) 796-8993

> From: Crawford, John[SMTP:John.Crawford@a...]
> Sent: Monday, January 18, 1999 7:48 AM
> To: ANSYS Users List
> Subject: [xansys] Re: Tet 95 Elements - Slower than Tet 92?

> From: "Crawford, John"

> Steve,

> I think I'd have have the 95-->92 conversion done automatically, with a
> user selectable option to keep all elements in the volume as 95's. The
> primary trouble with this scenario is adding the element type for
> SOLID92 to the element table. You can't assume that the user wants you
> to use a SOLID92 that is already defined in the element table. So,
> you'll have to define a new SOLID92 to the element table everytime a
> volume is meshed with transition elements.

> Of course, this all presents a problem when assigning attributes to mesh
> volumes, since the elements in this volume won't all have the same TYPE
> attribute. Strict element TYPE and volume TYPE associativity will be
> kaput.

> This whole deal screams for another solution. The cleanest and nicest
> would be to change the formulation for SOLID95 to be the equivalent of a
> SOLID92 if there are only 10 nodes present. So, if ANSYS detects a 10
> noded SOLID95 which appears to be a tetrahedral shape, then ANSYS will
> automatically use the SOLID92 computation algorithm. All of this is
> done underneath, and the user never realizes what is going on. You
> could add a KEYOPT to SOLID95 that would allow it to run tets as a 92,
> thus allowing the user to revert to the full 20 noded computation if he
> so desires.

> Following this one step further, this might be a good time to review how
> ANSYS handles degenerate elements in general, and see if there is a way
> to avoid carrying the unused DOF's through the entire analysis process.
> (This should keep you foks busy for a while!)

> John Crawford
> AlliedSignal Engines
> Phoenix, AZ
> john.crawford@a...

> From: Steve Owen
> To: 'xansys@o...'
> Subject: [xansys] Re: Tet 95 Elements - Slower than Tet 92?
> Date: Saturday, January 16, 1999 11:05AM

> From: Steve Owen

> Sorry to respond late to this thread. In thinking about ways to improve
> the pyramid transitions, I would appreciate some input about automating
> the TCHG command

> If the user is using 95s and does a tet mesh, is it reasonable to
> automatically convert all tets to 92s? If not, then under what
> circumstances should you do the automatic conversion? If there are any
> pyramids in the mesh? Should we provide a keyopt (flag) on 95s to
> specify "always convert to 92s when it is a tet"?

> Any comments on this would be appreciated.

> Steve Owen

> PS. There was a thread a few weeks ago regarding the FVMESH command. I
> have modified the FVMESH command to work with a set of detached
> elements. It is scheduled for release in Ansys 6.0.

> Steve Owen
> Senior Development Engineer
> ANSYS Inc., Pittsburgh, PA
> http://www.andrew.cmu.edu/user/sowen/

> > -----Original Message-----
> > From: Metrisin, Joseph T. [SMTP:metrisin@p...]
> > Sent: Monday, January 11, 1999 2:27 PM
> > To: 'xansys@o...'
> > Subject: [xansys] Re: Tet 95 Elements - Slower than Tet 92?

> > From: "Metrisin, Joseph T."

> > John,

> > You are correct. tet-shaped solid95's are much more expensive to
> > run than tet-shaped solid92's. ANSYS has a command called TCHG
> > to convert 95-tets to 92-tets. It is documented in version 5.5.1 but
> > is undocumented but available in 5.4. I agree that this should be
> > built into the transition meshing routines instead of having the user
> > run this command manually.

> > Joseph T. Metrisin

> > Structural Methods
> > Pratt & Whitney/Unitetd Technologies
> > M/S: 714-03
> > P.O. Box 109600
> > West Palm Beach, FL. 33410-9600

> > Phone: (561) 796-5967
> > Fax: (561) 796-8993

> > > From: Crawford, John[SMTP:John.Crawford@a...]
> > > Sent: Monday, January 11, 1999 2:11 PM
> > > To: ANSYS Users List
> > > Subject: [xansys] Tet 95 Elements - Slower than Tet 92?

> > > From: "Crawford, John"

> > > When ANSYS creates pyramid elements to transition from brick
> > elements
> > > (SOLID95) to tet elements (SOLID92) it makes them as SOLID95
> > elements.
> > > It also makes tet elements between the pyramid 95 and tet 92
> > elements,
> > > but it makes these transition tet elements as SOLID 95 elements too.
> > I
> > > was curious whether having SOLID95 tet elements instead of SOID92
> > tets
> > > woul have an impact on CPU time, so I made up a test case to
> > > iinvestigate.

> > > The test case was a cantilever beam (classic test problem...) fixed
> > on
> > > one end and loaded with a uniform pressure on it's top surface. The
> > > cantilever is made from 3 volumes. The end volumes are fairly
> > small,
> > > while the middle volume is constitutes maybe 75% of the total beam.
> > The
> > > volume on the fixed end was meshed using SOLID95 brick elements,
> > while
> > > the volume on the tip was meshed using SOLID92 tetrahedral elements.
> > > The large volume between them was meshed using SOLID95 pyramid and
> > tet
> > > elements, which ANSYS automatically makes for the transition between
> > > brick and tet element shapes.

> > > I saved this model, and then used a macro to modify the tetrahedral
> > > elements in the middle volume to be regular SOLID92 tets. I then
> > saved
> > > this model. Both models had 18306 degrees of freedom.

> > > I ran each model 5 times, using a macro to get the starting CPU
> > time,
> > > perform the solution, get the ending CPU time, and display the
> > elapse
> > > CPU time to me. The model which had SOLID95 tet elements averaged
> > > 34.82 CPU seconds to run, while the model which had all tets
> > configured
> > > as SOLID92 elements took an average of 22.74 CPU seconds. Very
> > > interesting. A big difference in speed.

> > > I'd appreciate hearing if anyone else has noticed this behaviour.
> > I'd
> > > also like to hear from someone at ANSYS Inc. why this takes place.
> > I
> > > have a good idea why, but I'd like to hear why this happens. Also,
> > now
> > > that the problem is recongized (assuming my test case is correct and
> > > other people duplicate it) would it be possible for ANSYS Inc. to
> > modify
> > > the meshing algorithm so it will create tets as SOLID92 elements so
> > we
> > > can have the fastest solution possible?

> > > I have appended the macro I wrote to convert the SOLID95 tet
> > elements to
> > > SOLID92 tets if anyone is interested in trying to confirm my
> > results.

> > > John Crawford
> > > AlliedSignal Engines
> > > Phoenix, AZ
> > > john.crawford@a...

> > > /nopr
> > > !
> > > ! brk2tet.mac a macro which converts degenerate SOLID95 tet
> > elements
> > > ! to SOLID92 tet elements
> > > !
> > > ! usage: brk2tet (no arguments)
> > > !
> > > ! written by: John Crawford date:1-6-99
> > > !
> > > ! check to make sure that we have elements selected
> > > *if,elmiqr(0,13),gt,0,then
> > > elid_=0
> > > ! create the type 92 element so we can create tets from bricks
> > > et,etyiqr(0,14)+1,92
> > > type,etyiqr(0,14)
> > > ! turn off shape checking and model associativity to avoid
> > > ! error/warning messages. they will be turn back on later.
> > > shpp,off
> > > modm,noch
> > > *do,i_,1,elmiqr(0,13)
> > > elid_=elnext(elid_)
> > > ! get the current elements mat, real, type values
> > > *get,mat_,elem,elid_,attr,mat
> > > *get,real_,elem,elid_,attr,real
> > > *get,type_,elem,elid_,attr,type
> > > ! get the element name to see if it is a 95
> > > *get,enam_,etyp,type_,attr,enam
> > > *if,enam_,eq,95,then
> > > ! check to see if this element has 10 nodes on it
> > > cm,node_,node
> > > cm,elem_,elem
> > > esel,s,elem,,elid_
> > > nsle,s
> > > ! if we have 10 nodes on this 95 element, convert it to
> > > ! a 92
> > > *if,ndinqr(0,13),eq,10,then
> > > ! set values for mat and real, so they will stay unchanged
> > > mat,mat_
> > > real,real_
> > > ! get the node numbers we need to create the 92 element
> > > n1_=nelem(elid_,1)
> > > n2_=nelem(elid_,2)
> > > n3_=nelem(elid_,3)
> > > n4_=nelem(elid_,5)
> > > n5_=nelem(elid_,9)
> > > n6_=nelem(elid_,10)
> > > n7_=nelem(elid_,12)
> > > n8_=nelem(elid_,17)
> > > n9_=nelem(elid_,18)
> > > n10_=nelem(elid_,19)
> > > ! modify the 95 element, converting it to a 92 and changing
> > > ! the node definition
> > > *msg,info,elid_
> > > Recreating element %i as a SOLID92 element
> > > emod,elid_,type,etyiqr(0,14)
> > > emod,elid_,-1,n1_,n2_,n3_,n4_,n5_,n6_,n7_,n8_
> > > emod,elid_,-9,n9_,n10_
> > > *endif
> > > cmse,s,elem_
> > > cmse,s,node_
> > > cmde,elem_
> > > cmde,node_
> > > *else
> > > *msg,info,elid_
> > > Element %i is not a SOLID95 element and was not recreated as a
> > SOLID92
> > > element
> > > *endif
> > > *enddo
> > > shpp,on
> > > modm,check
> > > *else
> > > *msg,info
> > > No elements are currently selected
> > > *endif
> > > /gopr

Posts possibly associated with message #297AuthorDateScore
177Tet 95 Elements - Slower than Tet 92?John Crawford1999/01/11 
179Re: Tet 95 Elements - Slower than Tet 92?Joe Metrisin1999/01/11 
180Re: Tet 95 Elements - Slower than Tet 92?Robert McClain1999/01/11 
183Re: Tet 95 Elements - Slower than Tet 92?Monte McGlaun1999/01/12 
195Re: Tet 95 Elements - Slower than Tet 92?Steve Ferguson1999/01/12 
284Re: Tet 95 Elements - Slower than Tet 92?Steve Owen1999/01/16 
287Re: Tet 95 Elements - Slower than Tet 92?Roberto Muccini1999/01/18 
288Re: Tet 95 Elements - Slower than Tet 92?Gerhard Mueller1999/01/18 
289Re: Tet 95 Elements - Slower than Tet 92?John Crawford1999/01/18 
297Re: Tet 95 Elements - Slower than Tet 92?Joe Metrisin1999/01/18