Troubleshooting - nimwegenLab/moma GitHub Wiki

• Frequently Asked Questions
• Gurobi errors
  • Gurobi library version error
  • Gurobi license error
  • MMPreproc module cannot be found

This error happened because the constraint that you entered manually by setting a cell or an assignment can't be handled by MoMA. Before restarting the curation from scratch, it's worth resetting the corresponding frame and/or transition: this should bring you back to the state you were at before setting the faulty constraint.

Setting the optimization range to a subset of the frames allows MoMA to perform optimization faster. Hence it is desirable to use the largest optimization range at which optimization is still very fast (typically 150-300 frames). In datasets where a few consecutive frames are particularly problematic, it is useful to transiently set a very short optimization range to fix these frames (since optimization might be run many times).

In practice, one wants to use the largest optimization range at which optimization is still very fast (typically 150-300 frames). Of course, the optimal solution found by MoMA can be impacted by missing additional information contained in future frames (close to the end of the range). The only documented case where this is problematic is the analysis of very difficult datasets where the user relies on a very short optimization range to produce a correct solution; when reloading the curation file, the optimal solution is likely to contain several mistakes since the results were checked with optimization run a local subsets of the data...

When the MoMA version is expired you will get an error message like this

along with log-output like this:

Warning: Gurobi version mismatch between Java 8.1.0 and C library 8.1.1
gurobi.GRBException: License expired 2023-07-16 - license file '/home/micha//Documents/LicenseFiles/gurobi9.lic'
	at gurobi.GRBEnv.<init>(GRBEnv.java:47)
	at com.jug.intialization.SetupValidator.checkGurobiInstallation(SetupValidator.java:13)
	at com.jug.MoMA.main(MoMA.java:74)
	at com.jug.exploration.ExplorationTestHelpers.startMoma(ExplorationTestHelpers.java:69)
	at com.jug.feature.Feature__20230719_add_flag_to_disable_multithread.run_interactive(Feature__20230719_add_flag_to_disable_multithread.java:40)
	at com.jug.feature.Feature__20230719_add_flag_to_disable_multithread.main(Feature__20230719_add_flag_to_disable_multithread.java:27)

You need to update your Gurobi license file. See how to obtain a gurobi license for details.

When trying to execute MoMA 0.9.x (which depends on Gurobi version 8.1) from a script that sets the Gurobi path with Gurobi version 10, you will encounter:

with the following stack trace:

java.lang.UnsatisfiedLinkError: no GurobiJni81 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
	at java.lang.Runtime.loadLibrary0(Runtime.java:843)
	at java.lang.System.loadLibrary(System.java:1136)
	at gurobi.GurobiJni.<clinit>(GurobiJni.java:261)
	at gurobi.GRBEnv.<init>(GRBEnv.java:43)
	at com.jug.intialization.SetupValidator.checkGurobiInstallation(SetupValidator.java:13)
	at com.jug.MoMA.main(MoMA.java:74)

The problem is caused by incorrect settings for the environment variables GUROBI_LIB_PATH and GUROBI_HOME, which need to be set correctly.

See Gurobi setup instructions how to set these variables correctly.

Furthermore, here are example script to launch MoMA on a local machine with the correct Gurobi environment variables settings (you will need to adapt them to your local setup as described in the Gurobi setup instructions):

• Example shell script to launch MoMA using Gurobi 8
• Example shell script to launch MoMA using Gurobi 10

Gurobi 10 supports a the Web License Service (WLS). This allows Gurobi to run inside containers, such as Docker containers provided the host/container has internet access. Therefore MoMA switched to Gurobi 10 to enable containerization (>=v0.9.8 for the v0.9.x releases; >=v0.10.2 for the v0.10.x releases).

Gurobi 8 does not support WLS. If you accidentally start a MoMA version that uses Gurobi 8 with a WLS license, you will get the following error:

gurobi.GRBException: No HostID specified in license file - license file '/home/micha/Documents/LicenseFiles/gurobi_web_license.lic'
	at gurobi.GRBEnv.<init>(GRBEnv.java:47)
	at com.jug.intialization.SetupValidator.checkGurobiInstallation(SetupValidator.java:13)
	at com.jug.MoMA.main(MoMA.java:74)

Use a non-WLS license with MoMA versions that use Gurobi 8 (i.e. non-containerized versions of MoMA). Use the WLS only with the containerized versions of MoMA.

When trying to run the containerized preprocessing the following error is encountered:

Lmod has detected the following error: The following module(s) are unknown: "MMPreproc"

Please check the spelling or version number. Also try "module spider ..."
It is also possible your cache file is out-of-date; it may help to try:
$ module --ignore-cache load "MMPreproc"

Also make sure that all modulefiles written in TCL start with the string #%Module

./20230830__lis__process_positions.sh: line 38: mm_dispatch_preprocessing.sh: No such file or directory
./20230830__lis__process_positions.sh: line 39: mm_dispatch_preprocessing: command not found

This can be caused when the preprocessing script contains the following lines:

module purge 
module load MMPreproc

These lines are used in the preprocessing scripts, when using the non-containerized preprocessing versions. However, the module name of the containerized preprocessing was changed. Therefore this directive will purge the containerized preprocessing module, but not reload it.

The solution is to remove these lines from the preprocessing script, when using the containerized preprocessing module.

You can get the following error:

gurobi.GRBException: HostID mismatch (licensed to 50df7412, hostid is c89b3cf8) - license file '/home/micha//Documents/LicenseFiles/gurobi9.lic'
	at gurobi.GRBEnv.<init>(GRBEnv.java:47)
	at com.jug.intialization.SetupValidator.checkGurobiInstallation(SetupValidator.java:13)
	at com.jug.MoMA.main(MoMA.java:74)
	at com.jug.exploration.ExplorationTestHelpers.startMoma(ExplorationTestHelpers.java:69)
	at com.jug.bugfix.Bugfix__20230807_fix_NullPointerException_in_ComponentForestDeserializer.run_export(Bugfix__20230807_fix_NullPointerException_in_ComponentForestDeserializer.java:56)
	at com.jug.bugfix.Bugfix__20230807_fix_NullPointerException_in_ComponentForestDeserializer.main(Bugfix__20230807_fix_NullPointerException_in_ComponentForestDeserializer.java:27)

This can occur when using a non-WLS, single-user Gurobi license, which is not expired. This license is bound to a specific machine through a HostID, which is stored inside the Gurobi license file.

The HostID will change, if Gurobi runs on a different machine or if you put the same machine on a different network (e.g. when working from home with the laptop home).

The license will then no longer be valid and you must request an additional license file for your new machine, or to work from home (see Gurobi setup instructions for details). Alternatively, you can use a WLS license, which is not bound to a specific machine or network (although I have not tested this personally).