XANSYS Message: 284 [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: Steve Owen
Date: 1999-01-16 13:05:00

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 #284AuthorDateScore
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