document when conda support breaks down (aka GLIBC errors) #21
Assignees
Labels
inwork
should appear in a release soon
Comments
jr3cermak
added a commit
that referenced
this issue
May 12, 2022
- add tests to ensure issue #21 stays resolved - when no land points are in the ocean grid, skip writing atmos/land exchange file
|
Reloading an environment that was previously stated as working may yield a result like this: This is an indication that the underlying system (or cluster) you are using is falling out of date. The supported python versions of modules managed by conda are under constant integration (CI) are are rebuilt using newer systems and hence are linked to more recent versions of GLIBC. On my particular system, the underlying GLIBC is version 2.12. One or more of the loaded python modules now requires GLIBC 2.14. Unless you have a backup of the conda environment, there is no way to recover the original operating environment. You will likely have to resort to conventional manual installation of modules to restore the environment. To see what your conda installation is using for GLIBC, use |
|
The second failure mode is updating the However, due to the age of your operating system, doing the above can render your conda unusable even though the above command will succeed! You may see the following error messages after updating for one or more of the conda commands: Again, there is no easy way to recover from this incident unless you have a backup of your conda installation directory. The only way to recover is to reinstall conda with a last known working version and reload your individual conda environments. If conda is broken beyond repair, there may be a way to salvage your environments. If you Process:
|
|
We have also discovered that this GLIBC issue is currently confined to one particular package: |
jr3cermak
added a commit
that referenced
this issue
Jun 3, 2022
- Fix tutorial rendering on github
- `local_instllation_tutorial.ipynb`
- `gridtoolAppTutorial.ipynb`
- Update gridtools manual
- `source/tutorials/jupyterMOM6.rst`: API updates to `computeBathymetricRoughness()`
- Update API documentation
- `bathyutils.py:computeBathymetricRoughness()`: By default, the user should
supply an extended grid prior to diagnosis of roughness. The user should
then clip the result to return the grid to the original dimensions.
- Update conda documentation
- Reolve issue #21
- Add commonly encountered problem to workarounds for jinja2.
- Add more metadata to written grid files.
- `grid_angleCalcMethod`
- `grid_resolution_x`, `grid_resolution_x_Units`
- `grid_resolution_y`, `grid_resolution_y_Units`
- `grid_gridResolution`, `grid_gridResolutionUnits`
- `grid_gridResolutionX`, `grid_gridResolutionXUnits`
- `grid_gridResolutionY`, `grid_gridResolutionYUnits`
- Example updates
- Make note to improve mkGridIterative with updated materials.
- `mkGridsExample4.ipynb`: improve metadata and comparison of the two
methods. Apply `angle_dx` fix for this grid.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The pinned versions of various pythonic items for gridtools still works. Conda support begins to break down when authors recompile prior versions with newer underlying operating systems. Pinned versions of compiled python modules will begin to fail on compute clusters with very old GLIBC libraries. Documentation to follow.
The text was updated successfully, but these errors were encountered: