[Nek5000-users] mesh problems

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

Hi Paul,

> We are presently working on all aspects of the workflow for large
> element counts.  (Yours is > 2.5x larger than any previous ones that I'm aware of.)
> 
> You can test your prex theory by running a case with just
> a few slabs in z.
> 
> Typically I would have n2to3 build the mesh with fairly
> large spacing in z and then use usrdat2() to recompress
> to the desired z range --- the reason for this is that
> genmap needs to identify the mesh topology based on the
> mesh geometry (i.e., the vertex locations), which requires
> distinguishing "coincident" vertices by the Euclidean
> distance separating them.  There are tolerances (as prompted
> in genmap) that give some control in making the proper
> distinction and the tolerance are relative, based on local
> edge length of the given elements.  In any case, this is a
> possible source of the error you're encountering.  Increasing
> the z spacing reduces the dimensionality of the difficulty
> so that z-separation is obvious.
> 

I faced the same trouble with 2.17 million elements. Let me follow your suggestion and 
set up a mesh in cell with z between 0 and 3 while keeping the x-y mesh exactly the same, 
just to check if the same errors occur. 

> Regarding the long runtime for matlab - yes, this is possible.
> (Obviously, extending this phase to parallel execution is a
> high priority for us.)  It's also possible that if the graph
> of the mesh were messed up (e.g., from genmap) then the matlab
> phase might take longer to find optimal coarsening/interpolation
> for amg.
> 

Yes, the one might be correlated with the other.  For 2.17 million elements it took 4 hours instead of
nearly four weeks.  

> A reasonable stategy at this point might be to increase the polynomial order, which would allow, say, a factor (10/8)^3 or (12/10)^3 reduction in the number of elements you need and thus significantly cut down on some of the difficulties you're encountering.
> 

This will help a bit, I agree.
Thanks,  Joerg.