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

Import opm-models #4627

Merged
merged 1,808 commits into from
Sep 3, 2024
Merged

Import opm-models #4627

merged 1,808 commits into from
Sep 3, 2024

Conversation

akva2
Copy link
Member

@akva2 akva2 commented May 4, 2023

It seems it's never a good time for this, but I'll open this PR for testing purposes so I can nip any problems out up front for when it is.

@akva2
Copy link
Member Author

akva2 commented May 4, 2023

jenkins build this please

@akva2
Copy link
Member Author

akva2 commented May 4, 2023

jenkins build this please

@bska
Copy link
Member

bska commented May 4, 2023

Tangential note: Do we know how much of doc/handbook we (i.e., the OPM project) have written? I would assume that at least some portion of it is from the Dumux project, but I have no idea how much.

@akva2
Copy link
Member Author

akva2 commented May 5, 2023

according to the git log, close to nothing.

@blattms
Copy link
Member

blattms commented Dec 5, 2023

There might not be a better time than now... (I am aware this needs to be discussed)

Actually, that might open the door to moving the material law managers from opm-common to opm-simulators which might make supporting adaptivity a tad easier.

@aritorto
Copy link
Member

aritorto commented Dec 5, 2023

I'm currently working on supporting LGRs on EclThermalLawManager, namely, getting the field properties of type int and double for a leaf grid view with LGRs, and it would be more convenient if the files were located in opm-simulators.

atgeirr and others added 23 commits February 7, 2024 11:50
[bugfix] Do not try to save FLOWS or FLOWRES values for NNCs.
These parameters get referenced only in certain configurations.
Tag Certain Parameters As Maybe-Unused
adjust to output module accessor change
in particular the solventMeaning can lead to
out-of-bounds dereferences in updatePrimaryVariables
they used to use the same EWOMS_DIFFUSION_MODULE_HH
…diffusion

changing including guard name for two diffusionmodule
these have been deactivated for years
remove last remnants of property system macros
Remove unused EWOMS_RESET_PARAMS macro
it adds no simplicity and only obfuscates
it simplifies nothing, only obscures.
remove unused different propTagName and use paramName.
remove EWOMS_END_PARAM_REGISTRATION macro
it adds no simplicity and only obfuscates
it adds no simplicity and only obfuscates
@akva2
Copy link
Member Author

akva2 commented Sep 2, 2024

September is upon us. As previously agree I have updated this PR now. I hope this can be expedited quite fast so I don't have to update yet again.

@akva2
Copy link
Member Author

akva2 commented Sep 2, 2024

jenkins build this serial please

Copy link
Member

@bska bska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't reviewed the new files, other than modelTests.cmake, since I assume those are effectively copies of the corresponding files in the OPM-Models repository. We could probably drop the doc directory at some point as well.

The integration changes look good to me and the CI system confirms the build is green. I do however have a couple of questions about the integration itself

  1. What happens to the open PRs in OPM-Models?
  2. Do we not need the workaround for older compilers that don't have the floating-point overloads of std::from_chars()–i.e., PRs Don't Require Floating Point from_chars() Function opm-models#926 and fixed: use PROJECT_SOURCE_DIR opm-models#927?

@akva2
Copy link
Member Author

akva2 commented Sep 3, 2024

  1. They will have to be moved. There will always be PRs and Sep 1 was agreed upon back in April as the cut-off date to do this.
  2. Good catch. That is definitely an oversight and I have remedied.

@akva2
Copy link
Member Author

akva2 commented Sep 3, 2024

jenkins build this please

akva2 and others added 2 commits September 3, 2024 10:49
This commit broadens the scope of commit 2ad332e0b (PR OPM#922) to
apply to all compilers/libraries, not just Clang/libc++, which do
not have support for floating-point types in std::from_chars().
While hopefully a transient situation, this enables building the
parameter system with GCC versions prior to GCC 11.  We expect to
require version 11 in the not too distant future, though.  At that
point we should revert this commit.

We use a configure-time feature test of the compiler (CMake command
'try_compile') to detect whether or not the compiler supports
floating-point overloads of std::from_chars() and emit the result to
config.h as the new preprocessor symbol

    HAVE_FLOATING_POINT_FROM_CHARS

We use std::strtod() as the fall-back alternative for floating point
conversion if this symbol is defined to false (zero).
@akva2
Copy link
Member Author

akva2 commented Sep 3, 2024

jenkins build this please

@bska
Copy link
Member

bska commented Sep 3, 2024

What happens to the open PRs in OPM-Models?

They will have to be moved. There will always be PRs and Sep 1 was agreed upon back in April as the cut-off date to do this.

Okay, then I guess you'll get to assist the authors if they run into trouble. Probably not a huge problem, because other than the compositional stuff, PR OPM/opm-models#808 and maybe PRs OPM/opm-models#813 and OPM/opm-models#512 there does not seem to be a whole lot that's worthwhile to port.

@akva2
Copy link
Member Author

akva2 commented Sep 3, 2024

absolutely available to help, but it should simply be git format-patch and git am assuming it doesn't touch buildsystem etc.

Copy link
Member

@bska bska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

absolutely available to help, but it should simply be git format-patch and git am assuming it doesn't touch buildsystem etc.

Okay, very good. In that case I'll merge this to start the process of incorporating OPM-Models into OPM-Simulators.

@bska bska merged commit f3db660 into OPM:master Sep 3, 2024
1 check passed
@akva2 akva2 deleted the import_opm_models branch September 3, 2024 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.