OpenLCA crashing when running Monte Carlo

Question

I am currently trying to run Monte Carlo simulations on product systems. I am able to set up the calculation (i.e., choosing the LCIA and allocation method, number of simulations, etc.), but past this point when I hit the "start" button to begin the Monte Carlo, the software crashes. The text of the generated error file is given below. I am using openLCA version 2.1.0. Any advice on how to fix this issue would be appreciated.

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd5b492af1, pid=14512, tid=15372

#

# JRE version: OpenJDK Runtime Environment Temurin-17.0.5+8 (17.0.5+8) (build 17.0.5+8)

# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)

# Problematic frame:

# C  0x00007ffd5b492af1

#

# No core dump will be written. Minidumps are not enabled by default on client versions of Windows

#

# If you would like to submit a bug report, please visit:

#   https://github.com/adoptium/adoptium-support/issues

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

#

---------------  S U M M A R Y ------------

Command Line: -Xmx10000M -Dpython.console.encoding=UTF-8 --add-modules=ALL-SYSTEM

Host: Intel(R) Xeon(R) CPU E5-1603 v3 @ 2.80GHz, 4 cores, 31G,  Windows 10 , 64 bit Build 19041 (10.0.19041.2913)

Time: Fri Apr 19 16:11:26 2024 Pacific Daylight Time elapsed time: 218.661694 seconds (0d 0h 3m 38s)

---------------  T H R E A D  ---------------

Current thread (0x000001cf56f1b5a0):  JavaThread "ModalContext" [_thread_in_native, id=15372, stack(0x000000781f500000,0x000000781f600000)]

Stack: [0x000000781f500000,0x000000781f600000],  sp=0x000000781f5fd1b0,  free space=1012k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  0x00007ffd5b492af1

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j  org.openlca.core.matrix.solvers.mkl.MKL.solveSparseFactorization(J[D[D)I+0

j  org.openlca.core.matrix.solvers.mkl.SparseFactorization.solve([D)[D+19

j  org.openlca.core.matrix.solvers.Factorization.solve(ID)[D+18

j  org.openlca.core.results.providers.FactorizationSolver.solutionOfOne(I)[D+24

j  org.openlca.core.results.providers.FactorizationSolver.<init>(Lorg/openlca/core/results/providers/SolverContext;)V+123

j  org.openlca.core.results.providers.FactorizationSolver.solve(Lorg/openlca/core/results/providers/SolverContext;)Lorg/openlca/core/results/providers/ResultProvider;+5

j  org.openlca.core.results.providers.ResultProviders.solveLazy(Lorg/openlca/core/results/providers/SolverContext;)Lorg/openlca/core/results/providers/ResultProvider;+15

j  org.openlca.core.math.Simulator.solve(Lorg/openlca/core/matrix/MatrixData;)Lorg/openlca/core/results/LcaResult;+24

j  org.openlca.core.math.Simulator.nextRun()Lorg/openlca/core/results/LcaResult;+65

j  org.openlca.app.results.simulation.SimulationProgress.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+60

j  org.eclipse.jface.operation.ModalContext$ModalContextThread.run()V+15

v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000000

Register to memory mapping:

RIP=0x00007ffd5b492af1 points into unknown readable memory: c4 81 7b 10 54 34 f8

RAX=0x000001cf5782f088 points into unknown readable memory: 0x0000000e0000000b | 0b 00 00 00 0e 00 00 00

RBX=0x0000000000000006 is an unknown value

RCX=0x000001cf5782f084 points into unknown readable memory: 07 00 00 00

RDX=0x0 is NULL

RSP=0x000000781f5fd1b0 is pointing into the stack for thread: 0x000001cf56f1b5a0

RBP=0x0000000000000001 is an unknown value

RSI=0x000001d7613aa080 points into unknown readable memory: 0x00000b3000000001 | 01 00 00 00 30 0b 00 00

RDI=0x000001d7613aa084 points into unknown readable memory: 30 0b 00 00

R8 =0x000001d77188b080 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00

R9 =0x0 is NULL

R10=0x0000000000000001 is an unknown value

R11=0x0 is NULL

Answer 1

Hello iturner,

I am not 100% sure what is happening here. I would suggest two things:

• download the latest version of openLCA (2.1.1) so that we are on the same page,
• increase the Maximum memory usage in File ⇾ Preferences ⇾ Configuration.

If the issue remains, let's keep in touch in the comments.

Regards,

François

Comments

Thanks for the feedback.

Answer 2

I guess this is since the Monte Carlo simulation led to a non-invertible matrix, due to the random change of data set as uncertain. You can check by validating the database first (if it is not valid, also the MC will not work), then check whether you have "complicated" distributions (normal distribution with small means and large standard deviations can lead to strange results); an issue for the calculation is a matrix that contains linearly dependent rows / columns, e.g. two rows that are 0. This prevents a calculation.

Comments

Validation of the database led to a large number of many different types of error messages. For MC to work correctly, does the database have to have zero error messages during the validation step? Or must there just be no error messages associated with the processes involved in supply chain for which the MC is being run? For example, there are many errors listed for processes imported from the Agrifootprint 6.3 database indicating that the allocation factors in the process do not add to 1, though I'm fairly certain that these processes are not relevant within the supply chain I'm modeling. Other error messages that are appearing include:

- Impact factor with invalid flow property or unit (related to specific impact categories)
- Invalid category link (does not explain what in the process is invalid)
- Invalid exchange unit
- Internal ID of exchange is larger than last internal ID of process

Some of these error messages may be in processes that are relevant to the supply chain I am modeling, but not all of them are.

As an aside, this issue with Agrifootprint 6.3 processes appears to be specific to the causal allocation factors rather than the physical or economic factors. A brief look into these processes shows that this problem seems to be specific to flows of dinitrogen monoxide, which often occurs twice in the causal allocation box, once with a sum factor of 2 and once with a sum factor of 0. Not sure if this is contributing to my issues, but it could contribute to others so I thought I'd get it on the record.

---

Good that we have this explanation now - the calculation fails because of these errors in the database. Typically in ecoinvent or also Agribalyse systems, many processes in the database are linked in one calculation, so it is good to fix these errors before doing a calculation (and I would do this either by fixing the errors or by maybe redoing the database that contains these errors now, from scratch so to say). These errors should not come from us but be caused by a script etc. executed on the database. Good luck! The allocation though is indeed a mistake in the original Agribalyse database but the factors are close to 1 and  though incorrect will not influence the result a lot, and you can keep them.