Skip to content

Add DLO support for state variables manipulation

Atoli Huppe requested to merge dlo-failing-tests into master

What does this MR do?

This MR fixes some bugs related to data layout optimisation (DLO). The DLO changed the layout of the state variables from an array of structures to an array of structure of arrays (AoSoA).

This change requires a modification to the IonType interface, used to access and modify state variables. In particular a regex was used to collect the state variables names from the generated code. This MR modifies the regex (found in limpetcommon.py) to handle both DLO and non-DLO. The state variables accessors and mutators (found in sv_init.cc generated by generate_sv_init.pl) also require some tuning to handle the new DLO structure.

These modifications fix the MULTI_IF::adjust_MIIF_variables function as it failed to properly work because of the faulty state variable interface: the function was writing to the wrong memory locations. The correction to the put<type>SV functions fixes the problem.

The dup_IMP_node_state function was copying state variables from one node to another using memmove. This does not work with DLO builds because the node's data is not contiguous anymore. The state variables must be copied one by one using the provided IonType interface.

This MR fixes (for DLO builds):

  • IonType::get_sv_list, IonType::write_svs, IonType::read_svs, IonType::get_sv_type
  • get<type>SV and put<double>SV from sv_init.cc
  • MULTI_IF::adjust_MIIF_variables responsible for failing gradient tests (region_vs_gradient_based_heterogeneities-parallel and region_vs_gradient_based_heterogeneities-serial)
  • limpet::dup_IMP_node_state responsible for crashing test prepace-long

Related issues

Closes #335 (closed)

Author's checklist

  • Follow the Contribution Guidelines. Sign the CLA and add yourself to the list of contribtutors for your first contribution.
  • Describe your change in the CHANGELOG.md file in the top-level folder of the openCARP repository.
  • Apply the appropriate labels.
  • Does this commit add new dependencies? If no, just tick the box. If yes, please evaluate carefully if the additional dependency is a more sustainable option than including the functionality in own code. If the former, describe the dependency clearly, add them to the Software Management Plan and the installation instructions (*.md files, CMake files, Docker files etc.).

Reviewer's checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Contribution Guidelines.

Reviewer

  • Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

Maintainer

  • Review by assigned maintainer, who can always request/require the above reviews.
Edited by Axel Loewe

Merge request reports