Call back function or DLL in Dakota on Windows platform

[iaae]

I have been reviewing Dakota's ability in the Windows app and have successfully tested the cantilever example using the {interface/Analysis_drivers/'my_test.exe'}.

I am wondering if there is any direct call-back function interface or DLL that can be embedded into Dakota without having to modify the Dakota source? The advantage of a call-back or DLL API interface is the simulation code and Dakota can both be alive all the time without going through system call, file reading/exchange, batch process, etc.

Also, are any demos or samples available on the Windows platform? Your help is greatly appreciated.

Thank you.

[iaae]

After reviewing all exotic sim drivers using all sorts of Python, plugin, etc, I think a simple way without messing with the Dakota module is to use a simple runtime driver with a lightweight RPC client/server interface. Kind of curious about the effectiveness of this Q&A area.

[SailingShoes]

I was also hoping to use a dll api in C# to avoid all the analysis driver overhead/complication but I've no such luck. Could you please share your solution? I'm going to look more in to the CLI to see how bad dealing with the inter-process communication is.

[iaae]

On the WinX64 platform, our solution is to use an EXE as the SIM driver. When Dakota is needed in SIM, it dynamically loads a DLL that starts a RPC server service and calls CreatProcess("Dakota-EXE -i input.OPT...") thread with the OPT file pointing to the EXE driver. After the EXE driver receives the param/result request, it just makes a RPC client call to the DLL and requests SIM meshing/solve/eval/write objective function results. The process is repeated when the EXE gets another call from Dakota or till the user kills the Dakota thread in SIM, or when Dakota converges/thread-exit.

All these are done in MSVC but should be the same for C#. Hope these procedure is clear.

[iaae]

If you don't mind the burden of Dakota-related code in your SIM, you don't have to isolate them in dynamically on-demand load DLL and just start the RPC server, call the optimization process, and catch the EXE driver client RPC call-back.
Below is a good example of RPC client/server demo project with message/content passing:
https://www.codeproject.com/Articles/4878/Introduction-to-RPC-Part-2

Hope these help.

[SailingShoes]

Thank you! I appreciate the insight.