hexagon logo

Running Aview in Batch Mode On Headless Machine

I'm working with a heavily parameterized (lots of design variables) model and am trying to generate the adm/acf input files for a Monte Carlo through Adams Insight. Unfortunately the process of writing out the adm/acf input files for every Monte Carlo case (not even running the simulation) takes many hours (I suspect due to the number of design variables in the model). I was hoping to submit this process to our compute cluster to speed things up, but that system has no displays present.
 
With previous versions of Adams I was able to run aview in batch mode on a headless machine by connecting to a dummy Xvfb display (en.wikipedia.org/.../Xvfb), but Adams 2019.2 just throws these errors when I follow the same process (ip address replaced with XX.XXX.X.XX).
 
Tue Dec 15 12:46:02 2020 ERROR! pid[10285] failed to connect DS server.
Tue Dec 15 12:46:02 2020 ERROR! pid[10285] Failed to connect to DSServer, DS address="XX.XXX.X.XX".
Tue Dec 15 12:46:02 2020 SCA.SCASystemException - Failed to connect to DSServer, DS address="XX.XXX.X.XX". (ID=2028000000)
SCA.SCASystemException - Failed to connect to DSServer, DS address="XX.XXX.X.XX". (ID=2028000000)
 
Has anyone had any luck running recent version of aview headless? I have no issues running solver on the headless compute cluster but unfortunately the adm/acf generation process must be run inside aview.
Parents
  • Hi Michael,
     
    Try setting this in your script before launching Adams View:
    MSC_ADAMS_VIEW_SCA_REMOTING_OFF
    Just set it to have a value of '1', perhaps. I hope that that takes care of the SCA errors.
     
    Regarding the virtual framebuffer stuff & rtool: you can remove that rtool call in the script because I don't think that we have an X11 graphics driver anymore. I *think* that most virtual framebuffers now will work with the default 'OpenGL' setting, surprisingly..
     
    I wonder if setting that env variable lets things work for you?
     
    Fingers crossed,
    Kent
     
Reply
  • Hi Michael,
     
    Try setting this in your script before launching Adams View:
    MSC_ADAMS_VIEW_SCA_REMOTING_OFF
    Just set it to have a value of '1', perhaps. I hope that that takes care of the SCA errors.
     
    Regarding the virtual framebuffer stuff & rtool: you can remove that rtool call in the script because I don't think that we have an X11 graphics driver anymore. I *think* that most virtual framebuffers now will work with the default 'OpenGL' setting, surprisingly..
     
    I wonder if setting that env variable lets things work for you?
     
    Fingers crossed,
    Kent
     
Children
No Data