Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for pointers in OpenFAST Registry generated Pack and Unpack subroutines #1625

Merged
merged 17 commits into from
Jun 20, 2023

Conversation

deslaughter
Copy link
Contributor

@deslaughter deslaughter commented Jun 14, 2023

This pull request is ready to merge.

Feature or improvement description

This commit significantly modifies the OpenFAST Registry code which generated the Pack and Unpack routines so that it can support packing and unpacking pointers without loosing their associations. This was accomplished by creating a PackBuffer derived type which stores a buffer of bytes and a pointer index. The byte buffer replaces the DbKiBuf, IntKiBuf, and ReKiBuf and packs all data as bytes (int8) using the transfer intrinsic. As each pointer is encountered in any structure, c_loc is used to get the address and the pointer index in PackBuffer is searched. If the pointer is found (already encountered in another field), then the exisitng index is saved into the buffer; otherwise, the pointer is added to the index and the new index is saved into the buffer. If the pointer wasn't in the index, then the associated data is saved to the buffer. Unpacking is the reverse of this process.

Impacted areas of the software
OpenFAST Registry, all _Types.f90 files, NWTC Library, OpenFAST Library, Visual Studio projects

Additional supporting information
A new file ModReg.f90 was added to NWTC Library and contains generic routines for packing and unpacking data. ModReg.f90 is generated from a Python script, GenModReg.py in the parent directory. This script takes function prototypes and expands them for a variety of intrinsic types and array ranks. Generation of NWTC_Library_Types.f90 was added to the CMakeLists.txt and the SetErrStat function was moved into NWTC_Base.f90. This removes some of the manual copying when these files need to be updated. The MeshPack, MeshUnpack, DLLPack, and DLLUnpack routines were also updated.

Test results, if applicable
An OpenFAST regression test was added to verify the restart capability, and ensure that all data was being packed and upacked correctly. The test is 5MW_OC3Mnpl_DLL_WTurb_WavesIrr_Restart which is the same as 5MW_OC3Mnpl_DLL_WTurb_WavesIrr except modified to generate a checkpoint file. The test is run twice, which required modifications to executeOpenfastRegressionCase.py and then the final output is checked against the reference.

This commit significantly modifies the OpenFAST Registry code which
generated the Pack and Unpack routines so that it can support packing
and unpacking pointers without loosing their associations. This was
accomplished by creating a PackBuffer derived type which stores
a buffer of bytes and a pointer index. The byte buffer replaces the
DbKiBuf, IntKiBuf, and ReKiBuf and packs all data as bytes (int8) using
the `transfer` intrinsic. As each pointer is encountered in any
structure, `c_loc` is used to get the address and the pointer index
in PackBuffer is searched. If the pointer is found (already encountered
in another field), then the exisitng index is saved into the buffer;
otherwise, the pointer is added to the index and the new index is saved
into the buffer. If the pointer wasn't in the index, then the associated
data is saved to the buffer. Unpacking is the reverse of this process.
@andrew-platt
Copy link
Collaborator

I'm suspicious we haven't been generating the NWTC_Library_Types.f90 file with the registry automatically due to some customizations that were needed. I don't remember any of the details though. @bjonkman, do you remember why we didn't autogenerate the NWTC_Library_Types.f90 file?

@bjonkman
Copy link
Contributor

@andrew-platt, NWTC Library Types files were not originally going to be auto-generated because of the mesh data types, but then we started modifying it and eventually decided the other data types stored in the library needed some of the routines the registry could generate.... anyway, it looks like @deslaughter has fixed the reasons for NWTC_Library_Types.f90 not being auto-generated. The ModMesh_Mapping.f90 code still has some auto-generated routines that are added to the code by hand. That module could probably also be reorganized with a separate ModMesh_Mapping_Types.f90 source. We were reluctant to be changing and adding so many source files to the NWTC Library back in the day because we were still using a bunch of other codes that relied on the library. Since the data types in NWTC Library were fairly static, it wasn't a high priority to go back and update it later.

@deslaughter , With this change to the NWTC Library source files, all of the .vfproj files will need to be updated for building on Windows. The NWTC_Library_Types.f90 generation should also be added to the RunRegistry.bat file.

@andrew-platt
Copy link
Collaborator

Thanks @bjonkman for the info on the history!

@deslaughter
Copy link
Contributor Author

@bjonkman, thanks for the background, it's very helpful to know why things are the way they are. I'll update the vfproj files and RunRegistry.bat so that it works on Windows before merging.

@deslaughter deslaughter marked this pull request as ready for review June 15, 2023 22:02
@deslaughter
Copy link
Contributor Author

I've added NWTC_Lib to RunRegistry.bat updated the Visual Studio project files so NWTC_Library_Types.f90 can be generated from within VS. I also fixed several projects which wouldn't build because they were missing SeaState files and AeroDyn_C_Bindings builds as well.

@andrew-platt
Copy link
Collaborator

Could you regenerate Morison_Types.f90? A conflict got introduced with #1623

@deslaughter
Copy link
Contributor Author

@andrew-platt , the latest commit has the regenerated types files

This commit changes the extrap/interp routines used by the Registry and
Mesh to use Lagrange polynomials. This formulation allows for scalar
coefficients to be calculated and then multiplied by the values/arrays
to be interpolation. This should significantly reduce the number of
operations used by these routines.
This code was unintentionally left in from developing the new
pack/unpack functionality for the registry.
@andrew-platt
Copy link
Collaborator

Adding a note from a discussion with @deslaughter so that I remember this later:

So whenever the packbuffer encounters a pointer in a derived type. It converts it to a C pointer via C_LOC. It then stores this an array of C_PTR types. So the next pointer it finds, it can look through the array of pointers and see if it's already in there. If it's in the array, it stores the index where the pointer is located. If not, It adds a new index to the array and stores the pointer and then the data. The restore is the same, but in reverse. The pointer index is unpacked and if there is already a C_PTR in the array, then it converts that pointer into the appropriate fortran type via C_F_POINTER. If not, it allocates space for the data, unpacks it, and then saves the pointer in the index.

@andrew-platt andrew-platt merged commit 9f68217 into OpenFAST:dev-unstable-pointers Jun 20, 2023
19 checks passed
@deslaughter deslaughter deleted the f/RegPtrPack branch June 20, 2023 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants