Re: [Nektar-users] Some Newbie Questions about Nektar++

4 Sep 2022

      Hi Ilteber,

Please see my answers to the questions highlighted below. I hope this helps a bit!

1. Does IncNavierStokesSolver or any other solver support adaptive time marching? It seems to me that TimeStep, NumSteps, IO_CheckSteps, IO_InfoSteps, IO_CFLSteps are required by the solver. I was wondering if it would be possible to control the time step with e.g. a CFL number constraint? Then all IO_* (most importantly CheckSteps) can be expressed in terms of simulation time (not time step).

In terms of adaptive time stepping theres no support for this currently. We do have a local-time stepping equivalent called Sub-Stepping in the IncNavierStokesSolver which allows us to run CFL>1 however, its speed versus the imex schemes at a lower time-step are currently up for debate. Theres possibly a project underway to speed this up but running CFL <<1  is the best bet at the moment.

2. Is it possible to calculate the gradient of only one specific variable? The gradient module calculates the gradients of all variables which produces unnecessary data, slowing down post-processing and increasing the size of the files. Is there a better way than calculating the gradient and removing the unnecessary fields using removefield module?

No, unfortunately using the FieldConvert module theres no options to specify only one field. You can check this with FieldConvert -p proc:gradient. That should output the available options for the module. We can reduce the size of the files through use of the range option in FieldConvert to extract only the desired region or homplane option in the homogeneous solvers.

3. Where can I find a use of the isocontours module of FieldConvert? I couldn't figure out what kind of output it gives, and what it expects as input.

5.5.21 Isocontour extraction: iscontour module

Extract an isocontour from a field file. This option automatically take the field to an equispaced distribution of points connected by linear simplicies of triangles or tetrahedrons. The linear simplices are then inspected to extract the isocontour of interest. To specify the field fieldid can be provided giving the id of the field of interest and fieldvalue provides the value of the isocontour to be extracted.

FieldConvert -m isocontour:fieldid=2:fieldvalue=0.5 test.xml test.fld \
        test-isocontour.dat

Alternatively fieldstr="u+v" can be specified to calculate the field u + v and extract its isocontour. You can also specify fieldname="UplusV" to define the name of the isocontour in the .dat file, i.e.

FieldConvert -m isocontour:fieldstr="u+v":fieldvalue=0.5:\
  fieldname="UplusV" test.xml  test.fld test-isocontour.dat

The user guide provides two good examples here. It expects a mesh and the required solver settings (as one file or two) as well as an input field file (.fld or .chk) fieldid is the index of the variable, corresponding to the fieldname string. I usually just use fieldname as its more explicit and easy to understand. The output should be .dat which is just point data. This can be then directly loaded into tecplot or paraview.

4. Is it possible to map the results of a case to another where the meshes are neither at same refinement level nor at the same order?

Yes, for this we use the interpfield module of FieldConvert.

FieldConvert -m interpfield:fromxml=file1.xml:fromfld=file1.fld \
        file2.xml file2.fld

5. Is there a way to control solver tolerance? The standard residual level allowed seems to be 1e-09, and how can I change it?

Yes absolutely. With an you can either control it as a solverproperty and change the default value i.e. <I PROPERTY="IterativeSovlerTolerance" VALUE ="1e-09" /> which sets this as a default for all fields. or we can change it for each field within the GlobalSysSolnInfo tag.

For example:

        <GLOBALSYSSOLNINFO>
          <V VAR="u">
            <I PROPERTY="GlobalSysSoln"       VALUE="IterativeStaticCond" />
            <I PROPERTY="Preconditioner"       VALUE="LowEnergyBlock"/>
            <I PROPERTY="IterativeSolverTolerance"    VALUE="1e-8"/>
          </V>
      </GLOBALSYSOLNINFO>

Which sets the linear solver, preconditioner and iterative tolerance for the x velocity.

6. When visualising with ParaView (and also if you write a python script), the best way I know is to convert the chk files into vtu files. In each of those vtu files, the mesh is included, which increases its size. Is there a way to use one mesh file (e.g. mesh.vtu or mesh.xml) and only convert the variables to some other format? This would reduce the storage space needed for a case. I would also appreciate it if you can suggest a totally new and a better way of visualising the results.

There's some work being done on the way we deal with vtu files at the moment. https://doc.nektar.info/userguide/latest/user-guidese20.html#x33-1440005.2.1 Have a look here. This was included in v5.2.0 which does change the way we handle post-processing a bit and improves the way we deal with the data. We can now deal with a multi-block dataset which allows us to investigate boundaries etc directly. This is also compressed binary rather than ascii (legacy vtu) which reduces the size fairly significantly. I don't think we have got to dealing with time-series yet - however, its on the list of things to look at I believe.

7. In the mesh.xml file created by NekMesh, the NUMMODES of the expansions are always 4, irrespective of the value of the ORDER parameter. Are those just placeholders, or should I change them after meshing? In the session file I set the NUMMODES as 1 + "the value of ORDER (in the mesh file)". Is this the correct way?

These are just so we can deal with the mesh directly as FieldConvert will require these. I usually tend to delete these - but they can be left as long as you specify your session file (if you're using 2 files) after your mesh - otherwise these overwrite the ones in the session file.

8. When using AeroForces filter, can you change the formatting of the output file? For example I want the time and the forces in scientific format with 10 digits precision, how can I make this happen?

With regards to formatting - there aren't any options to format the file specifically like this. Your best bet for this one is to have a look into the filter itself and modify explicitly and recompile.  If you look in library/SolverUtils/Filters/FilterAeroForces.cpp you should be able to mess around with the output stream and get the formatting the way you want.

Again, hope this helps a little bit!

Best of luck!

Kind Regards,
James Slaughter.

________________________________
From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of İlteber Özdemir <rilteber@gmail.com>
Sent: 30 July 2022 12:28
To: nektar-users <nektar-users@imperial.ac.uk>
Subject: [Nektar-users] Some Newbie Questions about Nektar++

This email from rilteber@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.

Hello,

I am a beginner in Nektar++ and have compiled some of my questions below. I would be glad if you can help.

1. Does IncNavierStokesSolver or any other solver support adaptive time marching? It seems  to me that TimeStep, NumSteps, IO_CheckSteps, IO_InfoSteps, IO_CFLSteps are required by the solver. I was wondering if it would be possible to control the time step with e.g. a CFL number constraint? Then all IO_* (most importantly CheckSteps) can be expressed in terms of simulation time (not time step).