Subject: Re: A tricky modelling/meshing problem. Any tips? Author: Jan Christian Anker Date: 2002-03-12 11:05:00Hi,
high (very high) element aspect ratios are ok if "the action" (i.e. deformations, stress gradients) is in a direction normal to the long side. (Think of a long, thin plate 1 thick, 100 wide, 1000 long that bends about a normal to the long side. If you model it with elements 1 by 1 by 100 so you get 1000 elements in the longitudinal direction, you will be fine). However, if there is twist about the longitudinal direction or you want to consider effects at the boundaries, this kind of modeling will not do.
Best regards, Jan Christian Anker
ANKER - ZEMER Engineering A/S e-mail: jc.anker@a... Phone: +47 22 13 95 80 FAX : +47 22 13 95 95 Address: Grindbakken 1, N-0764 OSLO, Norway > Web Page: http://www.anker-zemer.com Founding Member of Technology Network Alliance, Web Page http://www.technet-alliance.com
> -----Original Message----- > From: sti_sti2000 [SMTP:sis@h...] > Sent: Tuesday, March 12, 2002 4:12 PM > To: xansys > Subject: [xansys] Re: A tricky modelling/meshing problem. Any tips?
> Thanks again, Martin.
> I did mean 150000 elements, because this is the number that I noticed > when I looked at the warning dialogs (how many of the newly created > elements had bad geometry). I guess with Solid45 elements, this then > is roughly the amount of nodes in my model.
> Regarding the solver, I believe the sparse solver was chosen by > default. I just looked at my solution control box, and I have been > leaving it to "program chooses". The error report I saw on filling up > the hard disk was an error relating to the sparse solver so I suppose > this is the one automatically chosen.
> I notice that a lot of large files get created during my larger > simulation. These, and the page file completely filled up my hard > disk with the model of this size. If you suspect that this should not > have happened, then this is interesting.
> To anyone else looking in on this thread, I still am quite interested > in any thoughts on the original question: how to best mesh when the > model has a mix of very thin and very thick/long elements.
> Steven Isaacs > Hymite Aps > DTU, building 325 > Lynby, Denmark
> --- In xansys@y..., Martin Liddle wrote: > > In article , sti_sti2000 > > writes > > >My PC is a Hewlett Packard Vectra VL 800 with Pentium IV 1500 MHz > > >CPU, 1.5 GB RDRAM. I am using Linux RedHat 7.2. At the moment I > only > > >have about 8 GB available for Linux on this machine (it is a double > > >boot with Windows but I prefer Linux) and the Linux partition is > > >ext3. I am aware that ext3 is slower, and I intend to grab some > more > > >disk space from Windows and make it a Linux ext2 for my Ansys work.
> > That all sounds reasonable to me.
> > >I didn't notice the dimensionality of the problem that filled up my > > >hard disk, but I guess there were around 150000 elements, maybe > more. > > >I was doing a structural solution, so 3 DOF's per element. I am > using > > >Solid45 elements.
> > Something is confused; do you mean 150000 nodes 3 DOF per node > which > > would be 450000 DOF which should be easily soluable on your > hardware. > > Be aware that SOLID45 will be less tolerant of extreme aspect > ratios > > than SOLID95. Stay with SOLID45 for now.
> > >I would really be interested in knowing about the memory settings, > if > > >they could be adjusted away from the Ansys installation default to > > >make things work better. For example, I can't see why I am only > > >asking for 64 or 128 MB RAM under Ansys when my machine has 1.5 GB > in > > >it.
> > Memory allocation is much less important than it used to be as > dynamic > > allocation is now used for pretty much everything. Don't worry > about it > > just yet.
> > >Any tips for enhancing performance are much appreciated!
> > The most important choice will be the solver. You haven't told us > which > > solver you are using. The default is the Sparse which is robust > and > > accurate but even at 6.0 requires a fair amount of disk space. I'd > > recommend the PCG solver (EQSLV,PCG) which requires something like > 1 > > MByte of RAM for each 1000 DOF. So if your problem is 450000 DOF > then > > you have plenty of memory.