Is it possible to run simulations in DWSIM from a python script Outside of DWSIM? I read on the wiki that DWSIM has a TCP server module. Is there some sort of python API that allows a developer to communicate with a running DWSIM TCP server to run a flowsheet? I understand that the point of the TCP server is to have DWSIM communicate with another DWSIM, but I'm asking for python communicating with DWSIM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had problems last June installing pythonnet on Linux. There was no package available on any conda channel and building from source failed (see: https://github.com/pythonnet/pythonnet/issues/609 ). It looks from the thread like the problem may not yet have been completely fixed, but I haven't tried again in a while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I am trying to run simulations and interface with objects in DWSIM from outside of DWSIM using pythonnet. I am using macOS. I have pythonnet installed successfully, but when I run
import clr
clr.AddReference("DWSIM")
I get error: System.IO.FileNotFoundException: Unable to find assembly 'DWSIM'.
what do I need to do to get pythonnet to find DWSIM? I read the Automation wiki but it does not seem relevent to macOS and pythonnet. Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Adam - I know that is how I would do it on windows, but there is no "DWSIM.Automation.dll" file associated with the macOS installation. I just have "dwsim_newui.ini" and "DWSIM.app". How do I use automation on mac?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually pythonnet is workingfor me (I just needed to use mono). Even if I write a C# app, I still don't know how to add reference to DWSIM on mac. From the Automation wiki: "C# Console Application project and add a reference to DWSIM.Automation.dll, DWSIM.Interfaces.dll and CapeOpen.dll." There are no .dll files on mac installation. Please advise if it is possible to do automation with mac
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just checked that the macOS bundle doesn't include the automation DLL, I'm attaching it here and you can try copying the contents of the MonoBundle folder to another folder together with the automation DLL, to leave the app bundle intact.
I successfully added Reference to DWSIM .dll files. I have been stuck on the following step for some time. I realize this may be out of the scope of the support but if you have any quick suggestions please share.
in the following line:
interf = DWSIM.Automation.Automation()
i get the error:
System.DllNotFoundException: libgdiplus.dylib assembly:<unknown assembly=""> type:<unknown type=""> member:(null)</unknown></unknown>
i have installed mono-libgdiplus and the "libgdiplus.dylib" is located in the same MonoBundle directory as DWSIM.Automation.dll. Any suggestions?
Thanks so much for your help. I hope I can get the DWSIM automation working!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes - i found the issue though; having System.IO.Directory.SetCurrentDirectory('XXX') before clr.AddReference("System.Windows.Forms") solved that issue. I guess I was adding System.Windows.Forms.dll from another directory
But now I get new error in same line:
on running
interf = DWSIM.Automation.Automation()
I get error:
System.ArgumentNullException: Value cannot be null.
Parameter name: obj
Last edit: Ryan Stoddard 2020-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
System.ArgumentNullException: Value cannot be null.
Parameter name: obj
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_monitor_enter_v4_internal(object,intptr)
at ObjCRuntime.Class.GetClassHandle (System.Type type, System.Boolean throw_if_failure, System.Boolean& is_custom_type) [0x0003d] in <9155fee04bf94278bff2da17f42291d5>:0
at ObjCRuntime.Class.GetClassHandle (System.Type type) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at ObjCRuntime.Class.GetHandle (System.Type type) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSObject.AllocIfNeeded () [0x0001d] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSObject..ctor (Foundation.NSObjectFlag x) [0x00008] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSAutoreleasePool..ctor () [0x00000] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSMutableData.FromCapacity (System.nint capacity) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSData.FromStream (System.IO.Stream stream) [0x00060] in <9155fee04bf94278bff2da17f42291d5>:0
at System.Drawing.Icon.InitFromStreamWithSize (System.IO.Stream stream, System.Int32 width, System.Int32 height) [0x00000] in <72557f6049b84a4da6e034698e333b25>:0
at System.Drawing.Icon..ctor (System.IO.Stream stream, System.Int32 width, System.Int32 height) [0x00006] in <72557f6049b84a4da6e034698e333b25>:0
at System.Drawing.Icon..ctor (System.IO.Stream stream) [0x00000] in <72557f6049b84a4da6e034698e333b25>:0
at (wrapper remoting-invoke-with-check) System.Drawing.Icon..ctor(System.IO.Stream)
at System.Windows.Forms.ResourceImageLoader.GetIcon (System.String name) [0x0001c] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Form..cctor () [0x000f0] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/ryanstoddard/XX/chemsim/chemsim/hello.py", line 34, in <module>
interf = DWSIM.Automation.Automation()
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.Form' threw an exception.
at DWSIM.FormMain..ctor () [0x00000] in <af5ee662e7f54c3eb7e869efd34a588c>:0
at (wrapper remoting-invoke-with-check) DWSIM.FormMain..ctor()
at DWSIM.Automation.Automation..ctor () [0x0000c] in <8f82409bbb9a4a7d9ff5af9df16f112a>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <6ae2a9bbfe38412a965297a6b0a61fc2>:0 </af5ee662e7f54c3eb7e869efd34a588c></module>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using most recent Mono version 6.8.0. Maybe that is the issue? It seems most folks using pythinnet on mac are using Mono 5, perhaps I should try downgrading?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No no. 6.8.0 has a version of System.Drawing which does not require libgdiplus. Try removing System.Drawing from the directory where DWSIM files are located to see if mono will load its own assembly.
Last edit: Daniel Medeiros 2020-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
when i remove the System.Drawing.dll files i am back to the System.DllNotFoundException: libgdiplus.dylib error. Full error below;
System.DllNotFoundException: libgdiplus.dylib assembly:<unknown assembly=""> type:<unknown type=""> member:(null)
at (wrapper managed-to-native) System.Drawing.GDIPlus.GdiplusStartup(ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
at System.Drawing.GDIPlus..cctor () [0x000b0] in <b47030b20c7f490d8dae0e75a7c1548a>:0 </b47030b20c7f490d8dae0e75a7c1548a></unknown></unknown>
The above exception was the direct cause of the following exception:
System.TypeInitializationException: The type initializer for 'System.Drawing.GDIPlus' threw an exception.
at System.Drawing.StringFormat..ctor (System.Drawing.StringFormatFlags options, System.Int32 language) [0x00011] in <b47030b20c7f490d8dae0e75a7c1548a>:0
at System.Drawing.StringFormat..ctor () [0x00000] in <b47030b20c7f490d8dae0e75a7c1548a>:0
at (wrapper remoting-invoke-with-check) System.Drawing.StringFormat..ctor()
at System.Windows.Forms.ThemeWin32Classic.ResetDefaults () [0x0001f] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ThemeWin32Classic..ctor () [0x00006] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ThemeEngine..cctor () [0x00012] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></b47030b20c7f490d8dae0e75a7c1548a></b47030b20c7f490d8dae0e75a7c1548a>
The above exception was the direct cause of the following exception:
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.ThemeEngine' threw an exception.
at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Control..ctor () [0x000d6] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control..ctor()
at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/ryanstoddard/XX/chemsim/chemsim/hello.py", line 35, in <module>
interf = DWSIM.Automation.Automation()
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception.
at System.Windows.Forms.Control..ctor () [0x0000d] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ScrollableControl..ctor () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ContainerControl..ctor () [0x0000e] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Form..ctor () [0x00012] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at DWSIM.FormMain..ctor () [0x00000] in <af5ee662e7f54c3eb7e869efd34a588c>:0
at (wrapper remoting-invoke-with-check) DWSIM.FormMain..ctor()
at DWSIM.Automation.Automation..ctor () [0x0000c] in <8f82409bbb9a4a7d9ff5af9df16f112a>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <6ae2a9bbfe38412a965297a6b0a61fc2>:0 </af5ee662e7f54c3eb7e869efd34a588c></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></module>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to run simulations in DWSIM from a python script Outside of DWSIM? I read on the wiki that DWSIM has a TCP server module. Is there some sort of python API that allows a developer to communicate with a running DWSIM TCP server to run a flowsheet? I understand that the point of the TCP server is to have DWSIM communicate with another DWSIM, but I'm asking for python communicating with DWSIM.
You could use the automation interface, which is COM compatible and can be called from normal python distros.
But that requires windows only and not linux?
On Sun, Feb 17, 2019, 13:31 Daniel Medeiros danwbr@users.sourceforge.net
wrote:
http://pythonnet.github.io/
I had problems last June installing pythonnet on Linux. There was no package available on any conda channel and building from source failed (see: https://github.com/pythonnet/pythonnet/issues/609 ). It looks from the thread like the problem may not yet have been completely fixed, but I haven't tried again in a while.
Hi, I am trying to run simulations and interface with objects in DWSIM from outside of DWSIM using pythonnet. I am using macOS. I have pythonnet installed successfully, but when I run
import clr
clr.AddReference("DWSIM")
I get error: System.IO.FileNotFoundException: Unable to find assembly 'DWSIM'.
what do I need to do to get pythonnet to find DWSIM? I read the Automation wiki but it does not seem relevent to macOS and pythonnet. Thanks!
Try using clr.AddReferenceToFileAndPath. You must put the full path to the .dll file you are interested in. For example on windows:
clr.AddReferenceToFileAndPath("C:\Users\MyName\AppData\Local\DWSIM6\DWSIM.Automation.dll")
Hi Adam - I know that is how I would do it on windows, but there is no "DWSIM.Automation.dll" file associated with the macOS installation. I just have "dwsim_newui.ini" and "DWSIM.app". How do I use automation on mac?
I think that pythonnet does not work on macOS. You'll have to use VS for Mac and write a C# app, I guess.
Actually pythonnet is workingfor me (I just needed to use mono). Even if I write a C# app, I still don't know how to add reference to DWSIM on mac. From the Automation wiki: "C# Console Application project and add a reference to DWSIM.Automation.dll, DWSIM.Interfaces.dll and CapeOpen.dll." There are no .dll files on mac installation. Please advise if it is possible to do automation with mac
All DWSIM files are located in DWSIM.app/Contents/MonoBundle
Just checked that the macOS bundle doesn't include the automation DLL, I'm attaching it here and you can try copying the contents of the MonoBundle folder to another folder together with the automation DLL, to leave the app bundle intact.
Hi Daniel, thanks for the help and for the files.
I successfully added Reference to DWSIM .dll files. I have been stuck on the following step for some time. I realize this may be out of the scope of the support but if you have any quick suggestions please share.
in the following line:
interf = DWSIM.Automation.Automation()
i get the error:
System.DllNotFoundException: libgdiplus.dylib assembly:<unknown assembly=""> type:<unknown type=""> member:(null)</unknown></unknown>
i have installed mono-libgdiplus and the "libgdiplus.dylib" is located in the same MonoBundle directory as DWSIM.Automation.dll. Any suggestions?
Thanks so much for your help. I hope I can get the DWSIM automation working!
Did you copy System.Windows.Forms from the app bundle too?
Yes - i found the issue though; having System.IO.Directory.SetCurrentDirectory('XXX') before clr.AddReference("System.Windows.Forms") solved that issue. I guess I was adding System.Windows.Forms.dll from another directory
But now I get new error in same line:
on running
interf = DWSIM.Automation.Automation()
I get error:
System.ArgumentNullException: Value cannot be null.
Parameter name: obj
Last edit: Ryan Stoddard 2020-06-19
is there any error details? an exception object?
full error details:
System.ArgumentNullException: Value cannot be null.
Parameter name: obj
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_monitor_enter_v4_internal(object,intptr)
at ObjCRuntime.Class.GetClassHandle (System.Type type, System.Boolean throw_if_failure, System.Boolean& is_custom_type) [0x0003d] in <9155fee04bf94278bff2da17f42291d5>:0
at ObjCRuntime.Class.GetClassHandle (System.Type type) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at ObjCRuntime.Class.GetHandle (System.Type type) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSObject.AllocIfNeeded () [0x0001d] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSObject..ctor (Foundation.NSObjectFlag x) [0x00008] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSAutoreleasePool..ctor () [0x00000] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSMutableData.FromCapacity (System.nint capacity) [0x00001] in <9155fee04bf94278bff2da17f42291d5>:0
at Foundation.NSData.FromStream (System.IO.Stream stream) [0x00060] in <9155fee04bf94278bff2da17f42291d5>:0
at System.Drawing.Icon.InitFromStreamWithSize (System.IO.Stream stream, System.Int32 width, System.Int32 height) [0x00000] in <72557f6049b84a4da6e034698e333b25>:0
at System.Drawing.Icon..ctor (System.IO.Stream stream, System.Int32 width, System.Int32 height) [0x00006] in <72557f6049b84a4da6e034698e333b25>:0
at System.Drawing.Icon..ctor (System.IO.Stream stream) [0x00000] in <72557f6049b84a4da6e034698e333b25>:0
at (wrapper remoting-invoke-with-check) System.Drawing.Icon..ctor(System.IO.Stream)
at System.Windows.Forms.ResourceImageLoader.GetIcon (System.String name) [0x0001c] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Form..cctor () [0x000f0] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/ryanstoddard/XX/chemsim/chemsim/hello.py", line 34, in <module>
interf = DWSIM.Automation.Automation()
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.Form' threw an exception.
at DWSIM.FormMain..ctor () [0x00000] in <af5ee662e7f54c3eb7e869efd34a588c>:0
at (wrapper remoting-invoke-with-check) DWSIM.FormMain..ctor()
at DWSIM.Automation.Automation..ctor () [0x0000c] in <8f82409bbb9a4a7d9ff5af9df16f112a>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <6ae2a9bbfe38412a965297a6b0a61fc2>:0 </af5ee662e7f54c3eb7e869efd34a588c></module>
It seems to be a bug with mono: https://github.com/mono/mono/issues/10374
Do the same to System.Drawing as you've did with System.Windows.Forms to see if it works.
BTW, which Mono version do you have? libgdiplus.dylib was deprecated years ago.
The System.Drawing is not the issue.
I am using most recent Mono version 6.8.0. Maybe that is the issue? It seems most folks using pythinnet on mac are using Mono 5, perhaps I should try downgrading?
No no. 6.8.0 has a version of System.Drawing which does not require libgdiplus. Try removing System.Drawing from the directory where DWSIM files are located to see if mono will load its own assembly.
Last edit: Daniel Medeiros 2020-06-19
when i remove the System.Drawing.dll files i am back to the System.DllNotFoundException: libgdiplus.dylib error. Full error below;
System.DllNotFoundException: libgdiplus.dylib assembly:<unknown assembly=""> type:<unknown type=""> member:(null)
at (wrapper managed-to-native) System.Drawing.GDIPlus.GdiplusStartup(ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
at System.Drawing.GDIPlus..cctor () [0x000b0] in <b47030b20c7f490d8dae0e75a7c1548a>:0 </b47030b20c7f490d8dae0e75a7c1548a></unknown></unknown>
The above exception was the direct cause of the following exception:
System.TypeInitializationException: The type initializer for 'System.Drawing.GDIPlus' threw an exception.
at System.Drawing.StringFormat..ctor (System.Drawing.StringFormatFlags options, System.Int32 language) [0x00011] in <b47030b20c7f490d8dae0e75a7c1548a>:0
at System.Drawing.StringFormat..ctor () [0x00000] in <b47030b20c7f490d8dae0e75a7c1548a>:0
at (wrapper remoting-invoke-with-check) System.Drawing.StringFormat..ctor()
at System.Windows.Forms.ThemeWin32Classic.ResetDefaults () [0x0001f] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ThemeWin32Classic..ctor () [0x00006] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ThemeEngine..cctor () [0x00012] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></b47030b20c7f490d8dae0e75a7c1548a></b47030b20c7f490d8dae0e75a7c1548a>
The above exception was the direct cause of the following exception:
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.ThemeEngine' threw an exception.
at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Control..ctor () [0x000d6] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control..ctor()
at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0 </bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6>
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/ryanstoddard/XX/chemsim/chemsim/hello.py", line 35, in <module>
interf = DWSIM.Automation.Automation()
System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception.
at System.Windows.Forms.Control..ctor () [0x0000d] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ScrollableControl..ctor () [0x00000] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.ContainerControl..ctor () [0x0000e] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at System.Windows.Forms.Form..ctor () [0x00012] in <bc9e80be9c6b448884d58ed6c0fb31a6>:0
at DWSIM.FormMain..ctor () [0x00000] in <af5ee662e7f54c3eb7e869efd34a588c>:0
at (wrapper remoting-invoke-with-check) DWSIM.FormMain..ctor()
at DWSIM.Automation.Automation..ctor () [0x0000c] in <8f82409bbb9a4a7d9ff5af9df16f112a>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <6ae2a9bbfe38412a965297a6b0a61fc2>:0 </af5ee662e7f54c3eb7e869efd34a588c></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></bc9e80be9c6b448884d58ed6c0fb31a6></module>
try this: https://stackoverflow.com/questions/20820139/unity-and-system-drawing-on-os-x
unfortunately that did not fix the problem