OLAF: VTK outputs at non-equidistant grid points (nGridOut)

[RBergua]

Feature or improvement description
Currently, OLAF allows to extract information at points that are equidistant. For example:

4       nGridOut           Number of grid outputs.
GridName    GridType (1 = velocity, 2 = velocity and vorticity) TStart TEnd  DTOut XStart    XEnd   nX    YStart   YEnd    nY    ZStart   ZEnd   nZ
(-)           (-)                                                (s)    (s)   (s)   (m)      (m)    (-)    (m)     (m)     (-)    (m)     (m)    (-)
"1D"           1                                                  1     2    0.1    50       50      1     -75      75     20    100     100    1

Basically, OLAF does: linspace(Start,End,n).

However, sometimes, the user is interested in a non-equidistant distribution of grid points. See for example the requested points in the OC7 Phase III WP 3.2 project:

In this case, the discretization within the area covered by the rotor is a fine discretization of 0.25R while the discretization outside this area is coarser (0.3R). With the original nGridOut in OLAF, the user would have to define three grids to request all the information of interest. For example:
Grid 1: YStart: -2.5R, YEnd: -R, n: 6.
Grid 2: YStart: -0.75R, YEnd:0.75, n: 7.
Grid 3: YStart: R, YEnd: 2.5R, n: 6.

Since the project requests 6 hotwire arrays at 1D, 2D, 4D, 6D, 8D, and 10D downstream from the rotor, this would translate into 6*3 = 18 grids requested in OLAF. This is less than ideal because it writes many files at every time step and the user has to postprocess and consolidate them in a single file per hotwire array.

To avoid this, I have modified the grid table: a Start cell can be a number (equidistant, unchanged behavior) or a quoted filename (explicit list, one coordinate per line, strictly ascending order, without comments). This filename can be defined at the XStart and/or YStart and/or ZStart. Such file(s), e.g., “Ypoints.dat”, must be available in the same location as the OLAF input file.

When using the quoted filename (list-based), GridType must be 1. This list-based with non-equidistant points does not support the computation of vorticity (for reference, the vorticity is computed based on the gradient using the wind velocity and the distance between grid points).

All this logic is also included in the documentation: docs/source/user/aerodyn-olaf/InputFiles.rst

Below you can see an example requesting equidistant points (3 files as output + postprocessing) vs non-equidistant points (1 file as output without postprocessing):

For reference, when equidistant points are requested, the VTK file is written down using the StructuredPoints format. Example of the first file with the 6 equidistant grid points:

For non-equidistant points (new), the RectilinearGrid format is used. Example of the file with the 19 non-equidistant grid points:

Finally, in case the user tries to use the list-based approach and requests the vorticity, an error message will be printed:

Impacted areas of the software
OLAF VTK outputs (more locations available).

Test results, if applicable
This new feature does not impact the r-test. However, several verifications have been performed to ensure the proper behavior (see above).

[Copilot]

🟡 Not ready to approve

The new list-file parsing in ResolveGridAxis can silently ignore invalid trailing lines and lacks robust I/O/allocation error handling, which can lead to confusing or incorrect grid definitions.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR extends AeroDyn/OLAF grid VTK outputs to support non-equidistant grid coordinates by allowing XStart/YStart/ZStart to reference a coordinate list file, switching VTK output to RectilinearGrid when any axis is list-defined and restricting vorticity output to equidistant grids.

Changes:

• Adds explicit coordinate arrays (xPts/yPts/zPts) and list-file fields to GridOutType, including copy/destroy and pack/unpack support.
• Updates OLAF input parsing to accept either numeric Start values (equidistant) or filenames (explicit coordinates) and resolves all axes to explicit point arrays.
• Updates grid-point usage and VTK writing to use explicit coordinates and select StructuredPoints vs RectilinearGrid, plus documents the new input capability.

File summaries

File	Description
modules/aerodyn/src/FVW_Types.f90	Extends GridOutType with explicit coordinate storage and serialization support.
modules/aerodyn/src/FVW_Subs.f90	Switches grid point generation to use resolved coordinate arrays (plus whitespace cleanup).
modules/aerodyn/src/FVW_Registry.txt	Registers new GridOutType fields for the OpenFAST Registry system.
modules/aerodyn/src/FVW_IO.f90	Implements list-file parsing + axis resolution and selects VTK dataset type based on list usage.
docs/source/user/aerodyn-olaf/InputFiles.rst	Documents the list-based non-equidistant grid-point feature and constraints.

Review details

Suppressed comments (1)

modules/aerodyn/src/FVW_IO.f90:418

• ResolveGridAxis’s list-file parsing stops counting at the first non-numeric line (IOS>0) and then reads only the first n successfully read values, silently ignoring any trailing invalid lines (e.g., comments or blank lines). Also, the second-pass reads lack IOSTAT checks, so format errors can go undetected. This should treat any read error as fatal and report the offending line number.

      ! Count valid lines
      n = 0
      do
         read(UnList, *, iostat=IOS) val
         if (IOS /= 0) exit

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[andrew-platt]

This is a bit safer.

[andrew-platt]

We usually put the errstat setting at the beginning of the routine instead of end. This is ok as long as there is no way it could end prematurely.

[RBergua]

I have added the ErrStat at the beginning and I have made the error reporting explicit in ResolveGridAxis.

[andrew-platt]

see above for capturing allocation errors.

[RBergua]

@andrew-platt: For a reason that I still don't understand, I get the expected behavior when I compile locally with GCC 15.2.0. For example, I can see all the expected messages in the console:

However, when I compile with GitHub Actions (Intel Fortran compiler), the messages do not appear.

For reference, I'm runninng the exact same input files and compiled the same source code.

The code always works and the logic is the expected one. But the messages are not in the console. What is surprising to me is that this is at a global level. For example, if I define DTfvw with a very small value, I should get this message:

DTfvw must be >= DTaero from AD15.
AeroDyn Driver encountered simulation error level: FATAL ERROR
Aborting AeroDyn_driver. 

However, with the Intel Fortran compiler, I just get:

AeroDyn Driver encountered simulation error level: FATAL ERROR
Aborting AeroDyn_driver. 

The behavior observed here reminds me this one: #3301