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 MESMER-M integration tests #501

Open
wants to merge 84 commits into
base: main
Choose a base branch
from

Conversation

veni-vidi-vici-dormivi
Copy link
Collaborator

@veni-vidi-vici-dormivi veni-vidi-vici-dormivi commented Aug 20, 2024

  • Tests added
  • Fully documented, including CHANGELOG.rst

@mathause
Copy link
Member

Thanks - can you save the coeffs as netCDF and not pickle (I know it's a bit more annoying but we want to move away from pickle)

@mathause
Copy link
Member

mathause commented Aug 23, 2024

I haven't looked into it so not sure what is going on but a bit strange that none of the environments get it right. I thought this does not have to be high priority but then it would be good to stabilize the numerics for memser-m. What helped for the covariance thingy was testing the code on cfc vs exo, which have different cpus with different sets of SIMD instructions. But I am not really working today - if I find time I'll take a look tomorrow or else after our retreat...

@mathause
Copy link
Member

mathause commented Oct 1, 2024

Do you happen to know if the estimates are stable for each OS? Could we do os-dependent tolerances? (Not asking you to sink more time into this PR atm...)

@veni-vidi-vici-dormivi
Copy link
Collaborator Author

Do you happen to know if the estimates are stable for each OS? Could we do os-dependent tolerances? (Not asking you to sink more time into this PR atm...)

Sorry for never replying to this, yes the estimates are different from OS to OS, I remember I needed to increase the tolerance somewhere for windows to also pass. I guess we could do OS dependent tolerances but it's kind of awkward, since the tolerance then depends on which OS you produced the data with originally. Like now with the data from macOS, windows would need a larger tolerance, but if we ever push a dataset that was generated with windows it would have to be the other way around... so I'm not sure. but I like #563, although it is going back to what we did in #402, but oh well.

@mathause
Copy link
Member

since the tolerance then depends on which OS you produced

Good point! Let's not do this.

@mathause
Copy link
Member

lambda_coeffs and hm_coeffs both have coeff as dimension and consequently the shorther one is broadcast to the size of the bigger. In this case lambda_coeffs has 24 entries along the coeff dimension of which only 2 are used.

@veni-vidi-vici-dormivi
Copy link
Collaborator Author

Yes I agree that that's not so nice and I also am not that convinced of having one parameter file per ESM anymore, so it's fine for me to have a file or netcdf group? 👀👀 for each statistical method. However, I still think it is good to have the lambda parameters also along a coeff dimension in case we or someone else ever implements different lambda functions.

@veni-vidi-vici-dormivi
Copy link
Collaborator Author

Ah okay we had that already, just without coordinates. Yeah I would keep the coordinates but we can revert the unique naming

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.

2 participants