[Nek5000-users] Problem with Genmap

[nek5000-users at lists.mcs.anl.gov]

Hi Holly,

Attached is a tarfile with a script "mkmesh" and a .usr file
that will take a regular square grid and compress it near the
center.   Compression has two components:

1) a tensor-product compression, similar to what you had

2) a pseudo-orthogonal grid concentration

The purpose of the second part is to avoid very high aspect
ratio cells, which really impact the conditioning of the linear
systems and consequently the iteration counts.

On this latter point, let me make a couple of comments/questions.

In your original script you had a compression factor of 0.7,
extended over 50 elements, which would give a largest to smallest
ratio of ~ 1.e-8 and you would end up with an aspect ratio of
approximately 1.e-6.

My guess is that you have something very near the origin that you
are trying to resolve and are not interested in the far field.
Because of the difficulties with high-aspect ratio elements
(which is common to all discretizations, but see pp. 24-26
of www.mcs.anl.gov/~fischer/pubhtml/jcp97.pdf for a discussion
related to the SEM), it might be of interest to consider an O-grid,
i.e., a cylinder, in which you can easily focus resolution and
maintain near unit aspect-ratio throughout the domain.  Attached
is an example mesh (in t.t2.gz).  I can also provide the scripts
used to generate this, if of interest.

Paul




On Wed, 26 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote:

>
> Hi Holly,
>
> I've posted this back to the list since it doesn't involve big
> data files and the resolution of the problem might be of interest
> to others.
>
> I think I see what's going on and have a couple ideas to fix it.
>
> Most likely, the reduction attained with 50 elements and a geomtric 
> progression of 0.7 is wreaking havoc either in the .rea file or in
> the tolerances within genmap.  A significant issue here is that
> the file format in the .rea file is in limited precision --- I think
> we can change that with little difficulty and still be compatible
> with the workflow.   We'll look into that on our end.
>
> A reasonable work-around, which is what I typically do, would be
> to rescale your element coordinates inside nek, and just use a uniform mesh 
> as the input.   I'll send along some code on how to
> do this shortly --- along with another approach that will also
> give you focused resolution at the origin without the high aspect
> ratio elements that will result from the tensor-product approach
> used here.
>
> Paul
>
>
>
> On Wed, 26 Jun 2013, Holly Johnson wrote:
>
>> Hi Paul,
>> 
>> My mesh is actually quite simple, I've had to reduce it from a much more 
>> complicated version because Visit couldn't handle the number of elements I 
>> was using.
>> 
>> This is my .box file :
>> 
>> linear.rea
>> 2
>> 1
>> #
>> #      linear.box
>> #
>> Box
>> -50 -50
>> -3. 0. 0.7
>> -3. 0. 0.7
>> SYM,   ,v  ,
>> Box
>> -50 -50
>> -3. 0. 0.7
>> 0. 3. 1.3
>> SYM,   ,   ,O
>> Box
>> -50 -50
>> 0. 3. 1.3
>> -3. 0. 0.7
>>   ,SYM,v  ,
>> Box
>> -50 -50
>> 0. 3. 1.3
>> 0. 3. 1.3
>>   ,SYM,   ,O
>> 
>> I get the error for any mesh tolerance value when the scaling coefficients 
>> are _<_ 0.7 or _>_ 1.3. However it works fine for _>_0.8 and _<_1.2. I 
>> assume therefore it is that the elements of the mesh near the center of the 
>> grid are just too small?
>> 
>> Thanks again for your help,
>> 
>> Holly
>> 
>> Holly Johnson
>> Masters Student at ONERA - DAFE
>> Département d'Aérodynamique Fondamentale et Expérimentale
>> 8, Rue des Vertugadins
>> 92190 - Meudon - France
>> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.tar.gz
Type: application/octet-stream
Size: 8545 bytes
Desc: 
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20130626/7eb834be/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.t2.gz
Type: application/octet-stream
Size: 59381 bytes
Desc: 
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20130626/7eb834be/attachment-0003.obj>