Problem 2548

Summary: Microelectronics Example Crashing With Macro File
Product: Examples/Advanced Reporter: Conrad Provost <prov8967>
Component: microelectronicsAssignee: damien.lambert
Status: RESOLVED FIXED    
Severity: minor CC: damien.lambert, igor.semeniouk, Koichi.Murakami, susanna, Vladimir.Ivantchenko
Priority: P4    
Version: 11.1   
Hardware: Apple   
OS: Mac OS X   

Description Conrad Provost 2023-06-08 19:54:52 CEST
When attempting to run the interactive mode of the 'microelectronics' example, the program would crash, however when running the associated 'microelectronics.mac' macro file within my Mac terminal alongside the execute command for the example ( ./microelectronics microelectronics.mac ), the visualize window would pop up, and disappear once the run was ended, however data was available in the output .root file.

In an attempt to troubleshoot, I removed the line of code in the 'microelectronics.cc' file that would automatically run the macro file upon the execution of the interactive mode. Upon execution, this yielded the interactive mode, and upon running the commands that are in the macro file one by one (/control/execute vis.mac, etc.), the program would respond well, visualizing the geometry, setting the particle type (proton), setting the particle's energy, and initializing the run, with everything appearing to work just fine.

Upon further troubleshooting, it seems as though the existence of the command '/run/beamOn 2' within the macro file is what is causing the crash, as removing it from the macro file results in the smooth operation of the program, whether it be in interactive mode, or in the command-line execution of that command. However, when re

I believe this is indicative of a bug within Geant's macro interpreter. This is because all of the commands from within the interactive terminal work fine. The only problem is when macro files are involved. 

Please reach out if you have any more questions about my problem.

Thanks,
Conrad
Comment 1 Vladimir.Ivantchenko 2023-06-12 16:09:26 CEST
Dear Koichi,

please, redirect this problem to me.

Vladimir
Comment 2 Susanna Guatelli 2023-06-15 03:27:45 CEST
This error does not appear in linux platforms and is not related to the advanced examples. Koichi, please, could you give a look?
Comment 3 Vladimir.Ivantchenko 2023-06-15 10:15:40 CEST
dear Susanna, Koichi,

this is advanced example microelectronics. Not clear what is the software environment in the case described in this report. It is well known that macro, prepared for the batch mode not necessary work properly in the interactive mode. A general G4 approach is that example maintainer should provide vis.mac. In this particular case, Damien Lambert <damien.lambert@cea.fr> intended to fix the issue.

Vladimir
Comment 4 Semeniouk 2023-06-20 14:50:54 CEST
Dear all,
 i see the two problems in this example.

1) The default macro name set to microelectronics.mac.
This macro executed vis.mac internally. This will create and close
opengl window even when application executed  in batch mode.

I can suggest remove invocation of vis.mac from  microelectronics.mac file.
Alternatively you can considering to use off-screen driver like TE'S_OFFSCREEN
to write graphics to file without creation of graphic window.

2) The second problem related to Mac computers with M1 CPU.
If you use opengl graphics driver and put the /run/beamOn NN command
in the same macro ( microelectronics.mac in this case ) the application
will crashed. This is known problem , the visualisation group working on it.

The possible work around:
 comment out /run/beamOn command and type it later by hand or
 replace /vis/open OGL command with /vis/ope TSG.
 The TSG driver not suffer from this error.

I would like propose to the developer of this application
replaces line 107 in microelectronic.cc with line:
UImanager->ApplyCommand("/control/execute vis.mac");

Remove first line "/control/execute vis.mac" from  microelectronics.mac macro
and remove unused microelectronics.in from the directory of this example  and from CMakeFile.txt. 

Cheers, Igor S.
Comment 5 Semeniouk 2023-06-20 16:17:27 CEST
Sorry,

the file microelectronics.in was use as input for Jenkins tests , must be keeping.
The name of off-screen driver TSG_OFFSCREEN or TSG_FILE.

Igor S.
Comment 6 damien.lambert 2023-06-20 17:05:39 CEST
Hello all
 I try with putty/xming and it seems that I see sometimes the same problems.
Not easy to identify
I will try tomorrow on my linux station.

Regards
Damien
Comment 7 damien.lambert 2023-06-21 09:24:30 CEST
Hello all

 I tried:
* on my linux station -> no pb
* on my linux station from a remote linux station -> no pb
* on my linux station from a remote windows laptop (with putty/xming) -> pb



Regards
Damien
Comment 8 Susanna Guatelli 2023-06-21 09:40:57 CEST
I tried on my linux platform connecting from windows with a MobaXterm terminal and I had no problem
Comment 9 Semeniouk 2023-06-21 09:49:55 CEST
Hi Susanna, Demien,
it will be strange if you observed the error appeared on new Mac with new Apple CPU cheep only ( see issue #170 ), runnining program on linux and windows.

Against putting visualisation commands like /vis/open OGL inside the
batch macros is not a good practice and may produce some side effects.

The best wishes, 
  Igor S.
Comment 10 damien.lambert 2023-06-21 11:07:13 CEST
Hello all,

if you agree, I suggest to add a "#" at the beginning of the line:
#/vis/open OGL 600x400-0+0
for my test configurations, it is ok.
are you ok with this suggestion?

regards
Damien
Comment 11 Susanna Guatelli 2023-06-21 23:14:01 CEST
yes, sounds good
Comment 12 Susanna Guatelli 2023-06-21 23:14:32 CEST
either comment or remove
Comment 13 damien.lambert 2023-06-22 09:13:40 CEST
Ok! I will commit this!
Comment 14 damien.lambert 2023-06-26 13:55:49 CEST
In the last git release, the "#" has been already added to the "/vis/open " line into the vis.mac file.
So I think, we could consider the 2548 pb fixed,

Regards
Damien