mesh generation code not stable with upgrades

bearecinos / smith_glacier

Experiments with Fenics_ice over Smith, Pope, and Kohler Glaciers; three narrow ∼ 10 km wide, interconnected West Antarctic ice streams (Note: this repository documentation is still a work in progress).

1 stars 0 forks source link

mesh generation code not stable with upgrades #8

Open bearecinos opened 2 years ago

bearecinos commented 2 years ago

Hi @dngoldberg,

I am not sure if this is an issue but I've updated all my environment including the mesh python dependencies ... and the new mesh files are still good to run the inversion correctly but the smith_glacier test fails, as the new mesh files have change slightly (see image below). As consequence the J_inv value varies by very little:

expected_J_inv = 566220228.1028463 old_meshfiles_J_inv = 566220228.1028472 new_meshfiles_J_inv = 560574375.5121378

This raises three questions:

Every update of dependencies the mesh configuration might change slightly. See image below
Can we make the smith_glacier test more tolerant? So we don't have to change the input data every time?
How bad is this?

Zoom to new and old mesh:

NEW

OLD OVER THE NEW

bearecinos commented 2 years ago

I haven't updated my env in bow but if we want keep the code reproducible we will have to update at some point.

dngoldberg commented 2 years ago

hi bea

wow -- this is surprising!

just so im clear -- do you think this is because of changes to the gmsh library? you have not updated mmg, right?

bearecinos commented 2 years ago

mmg stayed the same! so the dependency outside of python stays the same binaries ... the whole python environment got updated. This can come from anywhere (any python dependency ...) that is use in the code of making the mesh:

import numpy as np
from netCDF4 import Dataset as NCDataset
import gmsh
import meshio

bearecinos commented 2 years ago

It can be even down to just numpy... I don't know if its a big deal. Since we can fix the input data for the smith glacier test (again) and change the toml...

But every time we update and recompute the input data we risk of having a mesh which is a little different ...

I don't think this is a numerical model problem... because nothing inside the numeric's of fenics_ice changes ... the pre-processing of the data and how you build your input data is what its changing the results now. Or we can let the test have the old input files (so these never get updated) and just move on... The goal of our smith_glacier test anyways, is not to change the numerical core of fenics_ice in a way that the inversion result is not stable given a fix set of data ... basically our test is not testing the input.