Nektar issueshttps://gitlab.nektar.info/nektar/nektar/-/issues2022-07-20T07:45:45Zhttps://gitlab.nektar.info/nektar/nektar/-/issues/286Include VTK in CI "full" builds2022-07-20T07:45:45ZJeremy CohenInclude VTK in CI "full" buildsCurrently, the CI "full" builds of Nektar++ do not build with VTK enabled. If we want to ensure that the code can be built successfully with VTK enabled, this should be included.
The `NEKTAR_USE_VTK=ON` option needs to be added to the m...Currently, the CI "full" builds of Nektar++ do not build with VTK enabled. If we want to ensure that the code can be built successfully with VTK enabled, this should be included.
The `NEKTAR_USE_VTK=ON` option needs to be added to the main CI build/test script and relevant vtk packages need to be added to the package list files for each distro.Jeremy CohenJeremy Cohenhttps://gitlab.nektar.info/nektar/nektar/-/issues/262CTest verbose flag not being passed through to Tester2022-04-01T13:50:16ZJeremy CohenCTest verbose flag not being passed through to TesterI'm not clear if this is by design or whether it's a bug but the `Tester` executable that is called by `ctest` to run the tests has a verbose flag `-v`.
However, when running `ctest -V`, the verbose flag is not passed through to the `Te...I'm not clear if this is by design or whether it's a bug but the `Tester` executable that is called by `ctest` to run the tests has a verbose flag `-v`.
However, when running `ctest -V`, the verbose flag is not passed through to the `Tester` executable. The verbose output shown is from the CTest framework itself but no verbose output is shown from the tester code unless it is run directly (manually) and the `-v` flag is specified.Jeremy CohenChris CantwellJeremy Cohenhttps://gitlab.nektar.info/nektar/nektar/-/issues/261Add support to the testing framework to test for expected failures2022-04-01T13:30:49ZJeremy CohenAdd support to the testing framework to test for expected failuresAdd support to the `Tester` tool to enable testing for expected error conditions.
For example, if a required input value is not provided, verify that this case is handled and the code fails with a reasonable error message that highlight...Add support to the `Tester` tool to enable testing for expected error conditions.
For example, if a required input value is not provided, verify that this case is handled and the code fails with a reasonable error message that highlights the problem.
The suggestion for addressing this is to add an additional "metric" to the `Tester` tool, e.g. `MetricError`, enabling the developer to specify, when a given executable is run with a given input, that a particular error message is generated. For example:
```
<test>
<description>...</description>
<executable>...</executable>
<parameters>...</parameters>
<files>
...
</files>
<metrics>
<metric type="error" id="1">
<value type="fatal">RequiredMethod must be specified in the input file.</value>
</metric>
...
</metrics>
</test>
```
This will require the tester to be able to accept a non-zero return code from the executable in cases where an error is expected.v6.0.0Jeremy CohenJeremy Cohenhttps://gitlab.nektar.info/nektar/nektar/-/issues/240Nekmesh for 1D mesh2021-01-22T14:32:33ZGokulNekmesh for 1D meshI was looking to solve the 1D Helmholtz equation as a starting point to understand how Nektar++ functions. This system is given by:
u''(y) - u(y) = f(y), u(-1) = 0, u(1) = 0.
where the dash represents a derivative wrt to y. I have atta...I was looking to solve the 1D Helmholtz equation as a starting point to understand how Nektar++ functions. This system is given by:
u''(y) - u(y) = f(y), u(-1) = 0, u(1) = 0.
where the dash represents a derivative wrt to y. I have attached the gmsh file and msh file that I generated. When I pass this file to Nekmesh, I receive the following errors:
Fatal : Level 0 assertion violation
Where : /Users/gokul/nektar/utilities/NekMesh/OutputModules/OutputNekpp.cpp[673]
Message : Unknown element type
libc++abi.dylib: terminating with uncaught exception of type Nektar::ErrorUtil::NekError: Level 0 assertion violation
Where : /Users/gokul/nektar/utilities/NekMesh/OutputModules/OutputNekpp.cpp[673]
[untitled2.msh](/uploads/ca7a171e7639004c835548d4658b74ef/untitled2.msh)
[untitled2.geo](/uploads/8b8b7d240858e7e73123e85597d4f7c9/untitled2.geo)https://gitlab.nektar.info/nektar/nektar/-/issues/239FieldConvert interpolation doesn't read .pts files in scientific notation2022-03-31T09:56:32ZGanlinFieldConvert interpolation doesn't read .pts files in scientific notationAfter converting a file of .dat format to .pts format for FieldConvert interpolation, the interpolation gives NaN if the .pts file is in scientific notation. It looks that the "FieldConvert -m interppointdatatofld" module doesn't accept ...After converting a file of .dat format to .pts format for FieldConvert interpolation, the interpolation gives NaN if the .pts file is in scientific notation. It looks that the "FieldConvert -m interppointdatatofld" module doesn't accept the scientific notation.Ankang Gaoankanggao@ustc.edu.cnAnkang Gaoankanggao@ustc.edu.cnhttps://gitlab.nektar.info/nektar/nektar/-/issues/231Runner with Intel compiler & AVX2021-01-22T14:36:23ZGiacomo CastiglioniRunner with Intel compiler & AVXMost Nektar++ developers use gcc, but few users and hpc centers use Intel compiler as default/preferred compiler.
Should we add a runner with a Intel compiler?Most Nektar++ developers use gcc, but few users and hpc centers use Intel compiler as default/preferred compiler.
Should we add a runner with a Intel compiler?Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/issues/225extrude in NekMesh2022-04-22T07:06:13ZAnkang Gaoankanggao@ustc.edu.cnextrude in NekMeshwhen using the extrude module in NekMesh, all quadrilaterals (or triangles) should be defined in one composite. If not, like this
` <COMPOSITE>
<C ID="100"> Q[0] </C>
<C ID="111"> T[1] </C>
<C ID...when using the extrude module in NekMesh, all quadrilaterals (or triangles) should be defined in one composite. If not, like this
` <COMPOSITE>
<C ID="100"> Q[0] </C>
<C ID="111"> T[1] </C>
<C ID="222"> T[2] </C>
</COMPOSITE>`
error occurs:
[blackfriars:13848] *** Process received signal ***
[blackfriars:13848] Signal: Segmentation fault (11)
[blackfriars:13848] Signal code: Address not mapped (1)
[blackfriars:13848] Failing at address: (nil)
[blackfriars:13848] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7f369ed5d0e0]
[blackfriars:13848] [ 1] /home/agao/testcode/nektarpp/build/dist/bin/NekMesh(_ZN6Nektar9Utilities11OutputNekpp14TransferDomainESt10shared_ptrINS_14SpatialDomains9MeshGraphEE+0x17a)[0x562aaa]
[blackfriars:13848] [ 2] /home/agao/testcode/nektarpp/build/dist/bin/NekMesh(_ZN6Nektar9Utilities11OutputNekpp7ProcessEv+0x19a4)[0x5602b4]
[blackfriars:13848] [ 3] /home/agao/testcode/nektarpp/build/dist/bin/NekMesh(main+0x2d9e)[0x53a75e]
[blackfriars:13848] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f369e9cd2e1]
[blackfriars:13848] [ 5] /home/agao/testcode/nektarpp/build/dist/bin/NekMesh(_start+0x2a)[0x4a1d2a]
[blackfriars:13848] *** End of error message ***
Segmentation faulthttps://gitlab.nektar.info/nektar/nektar/-/issues/222Provenance to output file2022-04-20T08:04:56ZAndrea CassinelliProvenance to output fileAs Hdf5 is more widely adopted, reading provenance information (branch and commit related to generation of data fields) is less immediate than opening the Info.xml file and inspecting it. Some possibilities would be:
- Add brief docume...As Hdf5 is more widely adopted, reading provenance information (branch and commit related to generation of data fields) is less immediate than opening the Info.xml file and inspecting it. Some possibilities would be:
- Add brief documentation and/or utilities on how to use h5dump to read information more easily
- Add provenance information to output file (branch and commit ID mainly, or and tags for wider community who may not be updating quite as regularly)https://gitlab.nektar.info/nektar/nektar/-/issues/216Expand and Document In-situ Processing for fieldConvert Modules2022-03-31T11:26:07ZJames SlaughterExpand and Document In-situ Processing for fieldConvert ModulesDetermine which fieldConvert modules are applicable and currently work in-situ and include in current documentation. Would be good to expand this capability to more of the fieldConvert modules.Determine which fieldConvert modules are applicable and currently work in-situ and include in current documentation. Would be good to expand this capability to more of the fieldConvert modules.https://gitlab.nektar.info/nektar/nektar/-/issues/211Add flexibility to define user-level default configuration settings2022-04-01T08:59:16ZAndrea CassinelliAdd flexibility to define user-level default configuration settingsAdd facility to accept some sort of rc-type file/environment variables/etc, so that default values in the session file can be defined at a beyond-session file level -- especially useful in non-academic setting for e.g.:
- Smoothing with...Add facility to accept some sort of rc-type file/environment variables/etc, so that default values in the session file can be defined at a beyond-session file level -- especially useful in non-academic setting for e.g.:
- Smoothing with SVV (IncNavierStokesSolver)
- Choices of preconditioners and solver tolerances
- Turning off backup files (superceding #209)
- The feature might also provide added suggestions to the user for things that do not make sense or should instead be done (use of certain filters etc). This would fall also under the scope of improving usability of the whole codebase.
*Things to think about:*
- What mechanism do we use? rc files, xml-based or something else?
- How to make it solver-aware? For some solvers it may not be desirable to change the default behaviour.Dave MoxeyAndrea CassinelliSpencer SherwinGiacomo CastiglioniDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/issues/210Enable HDF5 by default2022-04-01T09:16:11ZAndrea CassinelliEnable HDF5 by defaultSince HDF5 is now mature and has been extensively debugged, we can consider making it the default option. However a bit of a blocker here is that right now, HDF5 requires parallel support, so we need to add support for `NEKTAR_USE_MPI = ...Since HDF5 is now mature and has been extensively debugged, we can consider making it the default option. However a bit of a blocker here is that right now, HDF5 requires parallel support, so we need to add support for `NEKTAR_USE_MPI = OFF`.Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/issues/188InterpPointDataToFld failure with repeated points2024-01-26T14:48:01ZZhen-Guo Yanyanzhg@mail.ustc.edu.cnInterpPointDataToFld failure with repeated pointsWhen there are points with the same coordinates in the .pts file, which is common on the element interfaces if the points in .pts are generated from slices of DG solutions, the interpolation gives wrong results.
Add a checking subroutin...When there are points with the same coordinates in the .pts file, which is common on the element interfaces if the points in .pts are generated from slices of DG solutions, the interpolation gives wrong results.
Add a checking subroutine to delete/average the points with repeated coordinates will solve this problem.v5.6.0Thibault LestangThibault Lestanghttps://gitlab.nektar.info/nektar/nektar/-/issues/176Interpfield broken in 2.5D setup2024-01-26T14:54:51ZAndrea CassinelliInterpfield broken in 2.5D setupInterpfield fails with "Out of bounds" message. This prevents being able to interpolate to new mesh and continue simulations.
Launch:
FieldConvert -m interpfield:fromxml=channel.xml:fromfld=channel.fld channel_new.xml channel_new.fld
[...Interpfield fails with "Out of bounds" message. This prevents being able to interpolate to new mesh and continue simulations.
Launch:
FieldConvert -m interpfield:fromxml=channel.xml:fromfld=channel.fld channel_new.xml channel_new.fld
[channel.fld](/uploads/b33ddff68503f983abb39a787a529a60/channel.fld)
[channel.xml](/uploads/0329f3e8afc903f1f493f78a6a525a6d/channel.xml)
[channel_new.xml](/uploads/bf6585f5208e2a69f86541f8f5c52f31/channel_new.xml)v5.6.0Mohsen LahootiMohsen Lahootihttps://gitlab.nektar.info/nektar/nektar/-/issues/149FieldConvert: confusing help parameters, unexpected runtime behaviour2023-10-20T08:29:24ZJeremy CohenFieldConvert: confusing help parameters, unexpected runtime behaviourThe `FieldConvert` tool provides misleading usage information. In particular, when working with checkpoint files, it is unclear from the help output that the original mesh also needs to be provided as a parameter.
When running with inco...The `FieldConvert` tool provides misleading usage information. In particular, when working with checkpoint files, it is unclear from the help output that the original mesh also needs to be provided as a parameter.
When running with incorrect inputs, the tool either doesn't display any error (4.4.1) or it provides error output that could be improved to better explain the problem (master).
__Usage__
The usage output shows:
```
Usage: FieldConvert [options] inputfile.ext1 outputfile.ext2
```
Nowhere in the list of _Available options:_ is the required mesh file input mentioned. However, in the _Example usage_ section of the output, it shows:
```
FieldConvert file.xml file_vort.fld file_vort.dat
(process file_vort.fld and make a tecplot output file_vort.dat)
```
In this text, it's not clear, if you're unfamiliar with the tool, what `file.xml` is.
__Running FieldConvert__
Taking as an example trying to convert a checkpoint from a run of the `IncNavierStokesSolver` using the `solvers/IncNavierStokesSolver/Examples/Cyl.xml` example as input, we have a checkpoint file, e.g. `Cyl_2.chk` as output.
If we wish to convert this checkpoint file to VTK format (.vtu), the following appears to fit the provided usage information:
```
FieldConvert Cyl_2.chk Cyl_2.vtu
```
Running this with the current release and the `-v` flag gives the following output:
```
Processing input fld file
InputFld CPU Time: 0.0252183s
OutputVtk CPU Time: 2.789e-06s
Total CPU Time: 0.267088s
```
This looks to have been updated in master since we now get the following:
```
Execution sequence:
InputFld -> ProcessCreateExp -> OutputVtk
InputFld: Processing input fld file
InputFld CPU Time: 0.0242754s
ProcessCreateExp: Creating m_exp if needed
ProcessCreateExp CPU Time: 6.841e-06s
OutputVtk: Writing file
Fatal : Level 0 assertion violation
OutputVtk can't write using only FieldData.
libc++abi.dylib: terminating with uncaught exception of type Nektar::ErrorUtil::NekError: Level 0 assertion violation
OutputVtk can't write using only FieldData.
```
...followed by a stack trace.v5.5.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/issues/116FieldConvert not working on Nodal Tris2023-10-20T08:28:23ZSpencer SherwinFieldConvert not working on Nodal TrisWhen trying to postprocess a nodal triangle (for example the Helmholtz2D_CG_P2_Nodes.xml file in library/Demos/MultiRegoins) the method fails. An initial inspection shows that it defaults to TriExp::v_extractDataToCoeffs which is current...When trying to postprocess a nodal triangle (for example the Helmholtz2D_CG_P2_Nodes.xml file in library/Demos/MultiRegoins) the method fails. An initial inspection shows that it defaults to TriExp::v_extractDataToCoeffs which is currently only set up to read the Modified Basis (rather than the Ortho baiss that the NOdalTris are based on). However even fixing this we get rubbish solution values despite the error being small in the test.v5.5.0