A case where the .log.lck file remaisn after the run of a graph

Jose Evora

I don't consider this is a bug of DNG. The FMU is who creates the file and should be the responsible for deleting it if it is necessary (when terminate is invoked). This file is not created by DNG so it is out of the scope of what DNG knows. The only solution I see to this is to add an operation in a menu to purge temporal folder but it will remove all, not only this file.

2020-12-16T12:19:49+00:00

jean-philippe tavella reporter

I don’t understand: the .log and .log.lck file are not created by DNG? See the image

‌

2020-12-16T13:16:04+00:00

jean-philippe tavella reporter

In addition, I see the 2 last lines in the .log file are missing:

[INFO] FMU termination time
[INFO] FMU Co-sim finished

Maybe due to an issue in OM FMU termination ?

‌

2020-12-16T13:19:54+00:00

Jose Evora

Yes, you’re right, it is a file in DNG. I’ve checked it and effectively it’s a problem of the FMUs. If you run this case in the shell you can see this log:

[2020-12-17 11:38:05] [INFO] Loading simx 
[2020-12-17 11:38:05] [INFO] simx loaded 
[2020-12-17 11:38:05] [INFO] Stepper class: Constant 
[2020-12-17 11:38:05] [INFO] Co-sim started
    Daccosim NG %%YEAR%%: version %%VERSION%% released %%DATE%%
    Start time: 0.0
    Stop time: 100.0
    CoInit method: Iterative Propagation
    CoInit max iterations: 20
    CoInit tolerance: 1.0E-5
    Stepper method: ConstantStep
    StepSize: 0.5
    Transmit derivatives: false
    Loading multithreaded : false
    Stepping multithreaded : true
    Termination multithreaded : true
    Output buffer size: 8192
    CSV cell separator: ,
    CSV decimal separator: .
    Output file: C:\Users\jevora\Downloads\tankYPipe\tankYPipe-20201217113805.csv 
[2020-12-17 11:38:06] [INFO] FMU loading time: 355.731 ms 
[2020-12-17 11:38:06] [INFO] Number of SCCs: 1 
[2020-12-17 11:38:06] [INFO] Final residual value: 0.0 
[2020-12-17 11:38:06] [INFO] SCC 1 - Iterative Propagation had 2 iterations. Pipeline stage 1 
[2020-12-17 11:38:06] [INFO] FMU init time: 21.1872 ms 
[2020-12-17 11:38:06] [INFO] FMU co-sim time: 88.2878 ms 

Process finished with exit code -1073740940 (0xC0000374)

However, If I run it in single thread, it works properly.

Also if I run it in debug mode but multithread I can see how several invalid memory access are happening when invoking terminate:

Exception in thread "main" java.lang.Error: java.lang.Error: Invalid memory access
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:593)
    at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
    at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
    at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
    at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
    at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
    at eu.simulage.daccosim.GraphExecutor.terminate(GraphExecutor.java:183)
    at eu.simulage.daccosim.GraphExecutor.execute(GraphExecutor.java:138)
    at eu.simulage.shell.Main.main(Main.java:69)

So, in my opinion, there is something wrong with these FMUs. If I remember well, in the past, we have discovered that some kind of FMUs were not able to be executed in parallel. Am I wrong?

‌

Best regards,