I wanted to be able to generate nonconformal meshes using NekPy. This required some additional NekPy bindings and making it possible to write movement data to Nektar++ XML files.
Nektar::SpatialDomains::Movement::WriteMovementmethod was added, so movement data could be saved in an XML file
Nektar::SpatialDomains::Movement::AddInterfacemethods were written, to support creation of movement data programmatically (and not just by parsing XML)
- NekPy bindings were written for
- Bindings for various other methods were written, where they were found to be useful. This included the
To make it possible to write movement data to an XML file, some more information about the composites and domains which interfaces and zones correspond to was needed. This required a few additional member variables and accessors for those classes, with corresponding modifications to the constructors. a
WriteMovement method was added which could write the
MOVEMENT section of Nektar XML.
In order to be able to build non-conformal meshes from scratch with NekPy, methods were written which could add zones and interfaces to the Movement class on-the-fly. This means it is now possible to build up a Movement object without having to read all of it in from an existing XML file.
A few argument and return-types had to be made
const in order to work with Python bindings. As these appeared to be situations that were well-suited to
constness, this was done rather than introducing a wrapper for the Python binding.
In addition to NekPy bindings for
Interface classes (and subclasses), bindings were added for the following methods of classes already available in NekPy:
New bindings were also written for the following classes:
These changes were needed to make it possible to create meshes from scratch using the Python bindings.
Unit tests were written for the new Movement-related methods.
TestAddGetZonescreates two dummy Zone objects, adds them to a Movement object, and then checks to see whether they are returned by the
TestAddGetInterfacescreates three dummy Interface objects, uses them to create 3 interface pairs on a Movement object, and then checks they are returned by the
TestWriteMovementassembles a simple
Movementobject then calls
Movement::WriteMovement. The resulting XML tree is then queried to make sure that all the Zones and Interfaces expected are contained within it.
Functions and classes, or changes to them, are documented.
User guide/documentation is updated.
Changelog is updated.
Suitable tests added for new functionality.
Contributed code is correctly formatted. (See the contributing guidelines).
License added to any new files.
No extraneous files have been added (e.g. compiler output or test data files).