Issues accessing the same materials.xml on subsequent runs

[peak-rvanderploeg]

Hey All,

I have Mechanical set up as a Docker container, running on Ubuntu 20.04 and hosted on a Windows 11 Machine.
Whenever I try to run multiple simulations in a row that utilize the same "materials.xml" the first iteration runs fine, but subsequent yield the following:

2024-06-27 13:37:41.130199 (Thread 0x00007ff7f07ee600) [DESIGNSPACE, info] ------------- : MaterialHelpers::ReadMatMLMaterialCollection - try to read materials from: /tmp/ANSYS.root.1/AnsysMechC731/Project_Mech_Files/materials.xml
2024-06-27 13:37:41.153266 (Thread 0x00007ff7f07ee600) [DESIGNSPACE, error] ------------ : ACT: ERROR:


COMException
  at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR (System.Int32 errorCode) [0x0000a] in <e85874d36dd54c51a7dcd93d72f2c404>:0
  at (wrapper cominterop) Ansys.Common.Interop.DSObjectsAuto.IDSMaterialGroupAuto.ImportMaterials(string,Ansys.Common.Interop.DSObjectsAuto.kMaterialImportFormat,Ansys.Common.Interop.DSObjectsAuto.IDSMaterialImportSettings)
  at (wrapper cominterop-invoke) Ansys.Common.Interop.DSObjectsAuto.IDSMaterialGroupAuto.ImportMaterials(string,Ansys.Common.Interop.DSObjectsAuto.kMaterialImportFormat,Ansys.Common.Interop.DSObjectsAuto.IDSMaterialImportSettings)
  at Ansys.ACT.Automation.Mechanical.Materials.Import (System.String materialURI, Ansys.Mechanical.DataModel.MechanicalEnums.Materials.ImportFormat format, Ansys.Mechanical.Materials.ImportSettings settings) [0x00195] in <b5ae8b81b01145e4b862b73c93791895>:0
  at (wrapper delegate-invoke) <Module>.invoke_callvirt_IEnumerable`1<Material>_Materials_string_ImportFormat_ImportSettings(Ansys.ACT.Automation.Mechanical.Materials,string,Ansys.Mechanical.DataModel.MechanicalEnums.Materials.ImportFormat,Ansys.Mechanical.Materials.ImportSettings)
  at Microsoft.Scripting.Interpreter.FuncCallInstruction`5[T0,T1,T2,T3,TRet].Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x00000] in <acc0ee9784964310a3b66e6b4111da63>:0
  at Microsoft.Scripting.Interpreter.Interpreter.Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x0004e] in <acc0ee9784964310a3b66e6b4111da63>:0
  at Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet] (T0 arg0, T1 arg1, T2 arg2, T3 arg3) [0x0006d] in <acc0ee9784964310a3b66e6b4111da63>:0
  at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet] (System.Runtime.CompilerServices.CallSite site, T0 arg0, T1 arg1, T2 arg2) [0x0008f] in <36eb5f65880940849439f66ee131c80f>:0
  at Microsoft.Scripting.Interpreter.DynamicInstruction`4[T0,T1,T2,TRet].Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x00000] in <acc0ee9784964310a3b66e6b4111da63>:0
  at Microsoft.Scripting.Interpreter.Interpreter.Run (Microsoft.Scripting.Interpreter.InterpretedFrame frame) [0x0004e] in <acc0ee9784964310a3b66e6b4111da63>:0
  at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet] (T0 arg0, T1 arg1) [0x0004d] in <acc0ee9784964310a3b66e6b4111da63>:0
  at IronPython.Compiler.PythonScriptCode.RunWorker (IronPython.Runtime.CodeContext ctx) [0x0001b] in <5bfc425f6b234d9e8e288d1813a4c701>:0
  at IronPython.Compiler.PythonScriptCode.Run (Microsoft.Scripting.Runtime.Scope scope) [0x00023] in <5bfc425f6b234d9e8e288d1813a4c701>:0
  at IronPython.Compiler.RuntimeScriptCode.InvokeTarget (Microsoft.Scripting.Runtime.Scope scope) [0x000c6] in <5bfc425f6b234d9e8e288d1813a4c701>:0
  at IronPython.Compiler.RuntimeScriptCode.Run (Microsoft.Scripting.Runtime.Scope scope) [0x00000] in <5bfc425f6b234d9e8e288d1813a4c701>:0
  at Microsoft.Scripting.Hosting.CompiledCode.Execute (Microsoft.Scripting.Hosting.ScriptScope scope) [0x00017] in <7e69c199dff34d18b1d20b6bb7f0df95>:0
  at (wrapper remoting-invoke-with-check) Microsoft.Scripting.Hosting.CompiledCode.Execute(Microsoft.Scripting.Hosting.ScriptScope)
  at Ansys.Mechanical.Scripting.ACTScriptEngine+<>c__DisplayClass25_0.<ExecuteLight>b__0 () [0x00000] in <349006bfd3474bed89036059739f5158>:0
  at Ans.Common.WB1ManagedUtils.TaskPoster+<>c__DisplayClass11_0`1[T].<Get>b__0 () [0x00000] in <a40fc04fa95c4e01a6170816ab2e58f1>:0
  at Ans.Common.WB1ManagedUtils.TaskPoster.PostTask (System.Action action) [0x00020] in <a40fc04fa95c4e01a6170816ab2e58f1>:0
  at Ans.Common.WB1ManagedUtils.TaskPoster.Get[T] (System.Func`1[TResult] func) [0x00019] in <a40fc04fa95c4e01a6170816ab2e58f1>:0
  at Ansys.Mechanical.Scripting.ACTScriptEngine.ExecuteLight (Microsoft.Scripting.Hosting.ScriptScope scope, System.String cmd) [0x00025] in <349006bfd3474bed89036059739f5158>:0
  at (wrapper delegate-invoke) System.Func`3[Microsoft.Scripting.Hosting.ScriptScope,System.String,Ansys.Mechanical.Interfaces.MechanicalPythonResult].invoke_TResult_T1_T2(Microsoft.Scripting.Hosting.ScriptScope,string)
  at Ansys.Mechanical.Scripting.ACTScriptEngine.ExecuteCode (System.String code, System.String scopeName, System.Boolean light, System.Collections.Generic.IDictionary`2[TKey,TValue] args, System.Collections.Generic.IDictionary`2[TKey,TValue] rets) [0x00033] in <349006bfd3474bed89036059739f5158>:0

I've confirmed that /tmp/ANSYS.root.1/AnsysMechC731/Project_Mech_Files/materials.xml exists in my container, so there shouldn't be an issue accessing that file. The only guess I have is that the first simulation locks/holds that file and doesn't release it after completing or failing and this is causing subsequent simulations to not be able to access it.

Any ideas on how to resolve this issue?

[dipinknair]

What is the Mechanical version?

[peak-rvanderploeg]

v241

[dipinknair]

Hi @peak-rvanderploeg , Do you mind sharing your workflow here ? If not, could you please mail to [email protected]. Are you using embedding or remote mode?
Please provide python -m pip freeze as well.

[dipinknair]

@peak-rvanderploeg I could not reproduce the issue. Could you please share material.xml ?