Conversation
|
thanks @fsalmon001. I have compiled parmmg2d now, so waiting to hear how to run with it |
|
Hi @tdcwilliams, it is in the attached file. Actually, with default options; you just need to add regrid=mmg in the numerics options |
|
Hi again @fsalmon001, I was able to compile nextsim after |
|
Hi @tdcwilliams, the USE_MMG=true is done in the environment file like env_compile_gnu_linux.bash. Indeed, with the container, you don't use them so you should add it in the container. Then, yes, you only need to use numerics.regrid=mmg or do not choose it, as when USE_MMG=true, MMG is the default choice in the options.cpp file (you can change it if you want). |
|
actually USE_MMG was unset, and it doesn't compile. Where is libmetis? I have in /opt/local/parmmg2d: and |
|
Hi @fsalmon001, |
|
Hi @fsalmon001, |
|
Hi @tdcwilliams, I just pushed a new commit for parmmg2d to have the correct installation path, which was not the case. Now the metis library is at the same location as the parmmg2d library |
|
Hi @fsalmon001 |
|
Hi @fsalmon001, Your fix was nicer though and also works. |
|
Hi @fsalmon001 |
|
Hi @tdcwilliams, |
|
Hi again @fsalmon001, For |
|
Hi @fsalmon001 |
|
Ok, I see, actually it was not really an error even if MMG complains about it @tdcwilliams h_min = coef_min * h_mid So to have a strictly uniform mesh, you need h_min = h_max, or at least, h_min almost equal to h_max. So, I would choose 0.999 and 1.001 for instance, to avoid the warning and still have a uniform mesh by default. You still have the issue with BAMG? |
|
yes I still have a bamg error, with this cfg file and 32 cpus |
…x closer together
|
I tried your case @tdcwilliams, but without the ocean model (constant instead) and the ice-type is piomas. I don't have the drifter file neither so I did not use drifters. And it works. I think I have only seen this kind of error, and if I remember well, it is related to an issue with a netcdf file (netcdf uses the argument ncuts in some functions). |
|
Hi @fsalmon001 Can you do this (NB remove |
|
Hi @tdcwilliams, I would agree with you, but we still use one interpolation function of BAMG (for nodes) in interpFields_parallel, so we cannot remove completly BAMG so far. And it is not as easy to remove it because this function calls other functions in BAMG. Moreover, on a supercomputer, I had an error in the node interpolation function, probably due to epsilon error and a point which was outside the domain for maybe 1e-14 m, and this caused a crash. So there is indeed not perfect functions in BAMG. So what do we do? I could do what you want relatively quickly I think. But maybe, before, you could try 2 km meshes for instance, to check everything is ok even with finer meshes and your configuration file (I don't have as many options as you in my tests). |
|
Yes, there is no need for us to have two remeshing methods, even though @fsalmon001 obviously needs to compare the two in his paper. But if we remove bamg, we need to update the Docker and Aptainer files in https://github.com/nansencenter/nextsim-env before merging into develop. |
|
Hi @fsalmon001, Hi @einola, |
|
I just thought of it @tdcwilliams, @einola, but when the paper will be under review, maybe the reviewers should have access to a version with MMG and BAMG to check and compare the results? Maybe we could let BAMG in this version, and I do another pull request to remove BAMG from the code after? My post-doc ends at the end of January, so we have enough time, it will be a quick PR. I also had a look on the interpolation function from BAMG, I think I can code another one, but not sure so far that I will be as quick as the original one. I will keep you informed |
|
Hi @fsalmon001, we can tag the current version of develop, and the one after this PR, if they want to compare bamg and mmg. |
|
Hi @tdcwilliams, yes that sounds good. For BAMG, I am not convinced that the bamg option is unstable in this PR, there is only one difference when using BAMG from the current dev branch, it is in the explicitSolve function, and the difference is epsilon. So, I don't see how this branch could bring issues when using BAMG compared to the current nextsim version. |
|
Hi @fsalmon001 same config as before but different mesh and timestep is 450s. |
|
yes I seem to get it every time there is a regrid |
|
The mesh seems ok? I am not sure the origin of the problem is in the metric computation if this happens everytime. Or this is a very particular case which is permanent here for some reason. |
|
I don't know about the mesh, but the moorings outputs seem ok. |
|
Ok, I will try to understand if this is theoretically possible. At least, this is not a critical error, rather an inaccurracy on the wanted metric. |
|
can I save some fields or something for you to test? |
|
Maybe, give me the log file of your run (with the LOG[DEBUG], etc) please? I could compare with mine to see when both simulations differ whereas we have the same config file. Maybe there is still an error in the code, and depending on the configuration, we have it or not |
|
In the 3 commits, I corrected:
|
There was a problem with the function finding if points are inside or outside the polygon. This fixes that, including some workarounds. I need to document it better, and some improvements are still needed.
It's not quite the same as skipping elements that have only undergone translation, but it helps with the small delta errors I've been having.
Following a previous commit, this tells checkIfInside what to return if the point is right on the border.
A comparison with zero is not very useful on a finite-precision machine! Using 1e-6 seems to work well.
These seem to be ints and the compiler complains that 1e15 is too big. So, I limited the size of elements to 1 m at the smallest and 100 thousand km (1e7) at the largest. We don't want elements that cover the entire earth!
The "major error" in InterpFromMeshToMesh2d should be fatal.
I was fiddling with it ans saw that I had already done something similar in ConservativeRemappingFromMeshToMesh. It probably won't have much of an effect. Putting it here, since these functions have been massively rewritten anyway.
Because it's a good thing!
checkIfIntersecting now ignores intersections that are exactly on the vertex. It never should have included those, and doing it like this is very marginally better in terms of total error.
|
This now works for every mesh I have tried, but I haven't tried the coupled ones yet. |
| ("numerics.metric_coef_min", po::value<double>()->default_value( 0.9999 ), | ||
| "Scale factor for minimum element size.") | ||
| ("numerics.metric_coef_max", po::value<double>()->default_value( 1.0001 ), | ||
| "Scale factor for maximum element size.") |
There was a problem hiding this comment.
| ("numerics.metric_coef_min", po::value<double>()->default_value( 0.9999 ), | |
| "Scale factor for minimum element size.") | |
| ("numerics.metric_coef_max", po::value<double>()->default_value( 1.0001 ), | |
| "Scale factor for maximum element size.") | |
| ("numerics.metric_coef_min", po::value<double>()->default_value( 0.9995 ), | |
| "Scale factor for minimum element size.") | |
| ("numerics.metric_coef_max", po::value<double>()->default_value( 1.0005 ), | |
| "Scale factor for maximum element size.") |
I need slightly different values here for high-resolution meshes. Do these look ok @fsalmon001 ?
There was a problem hiding this comment.
Hi @einola, it depends why you need such values.
Actually, the default values of metric_coef_min/max were good to ensure homogeneous remeshing and avoid the computation of the metric (in the function compute_optimal_metric).
For your values, if I didn't make a mistake, a quick computation shows that for 10 km meshes, you will compute the metric to have a quasi-homogeneous mesh. For 1-km meshes, I am not sure but maybe also.
There was a problem hiding this comment.
Hi @fsalmon001,
I needed to change them, because otherwise the model would crash with a message saying that mmgopt->hmin and mmgopt->hmax were the same value (I don't have the exact message now).
But you're right, I didn't get that for the 10 km mesh. I can check at which resolution this message appears, if that helps. Do I understand correctly that the optimal values for these parameters are expected to be resolution-dependent?
There was a problem hiding this comment.
Could you give me the exact message please when possible?
With values very close to 1, it is not resolution-dependent. With your values, it will be. However, the difference is only the computation of the metric, which should almost be constant so the output mesh should be about the same.
There was a problem hiding this comment.
## Error: hmin value must be strictly lower than hmax one (hmin = 1410.000000 hmax = 1410.000000 ).
Repeated very often for a mesh with a resolution of 1.25 km.
There was a problem hiding this comment.
(Actually, MMG tolerates constant metrics, but the check is not well done)
There was a problem hiding this comment.
Ah, I see. Ok, but then I'll remove this from my config files and try to run the high-resolution case. It's a bit strange that it doesn't appear all the time, as you expect, but let's not worry about that for now.
Thanks for the info!
There was a problem hiding this comment.
In MMG, we have this
if ( mesh->info.sethmax && ( mesh->info.hmin >= mesh->info.hmax ) ) {
fprintf(stderr,"\n ## Error: hmin value must be strictly lower than hmax one"
" (hmin = %lf hmax = %lf ).\n",mesh->info.hmin, mesh->info.hmax);
return 0;
}
info.hmin and info.hmax are equal to mmgopt->hmin and mmgopt->hmax. I think the error message should never appear but depending on the precision in the >=, it may happen I guess
There was a problem hiding this comment.
I see. I guess we could do something like
mmgopt->hmin -= std::numeric_limits<double>::min();
mmgopt->hmax += std::numeric_limits<double>::min();
right?
There was a problem hiding this comment.
mmgopt->hmin is not equal to mmgopt->hmax inside nextsim. It would be the case only if, in the options, the default values for numerics.metric_coef_max/min were strictly equal to 1. So, I don't think your workaround would work, the inaccuracy is greater
This is just to make comparison with the work in PR #684 easier.
Fixes a stupid bug, where I didn't calculate the displacement of the element correctly.
I didn't test it properly before pushing.
3 participants
Quick_user_guide.odt
Integration of parallel remeshing into nextsim using parmmg2d. The parallel interpolation is also added.
The use of BAMG is still possible.
There will be some minor differences with the develop branch even with bamg due to changes in the explicitSolve function (induce only machine precision errors).
To use parmmg2d, you must compile parmmg2d. It should be done by adding in the container:
I will edit this message and add a quick user guide for using the parallel remeshing this afternoon.