search

ORNL-Fusion / ips-wrappers

IPS wrapper / helper codes.
9 stars 4 forks source link

How to test a python wrapper without running the IPS? #12

Open dlg0 opened 9 years ago

dlg0 commented 9 years ago

@ORNL-Fusion/ips-support-team

I have an IPS simulation that ran up to some point, and crashed. I'd like to make changes to the wrapper and run just the wrapper to test it, but obviously I need to call the wrapper in the right way. What are the python commands I'd run (given that I'm in the work directory of a failed component) to re-run the wrapper?

Thanks.

elwasif commented 9 years ago

If the crash is in an actual code binary, then you simply need to run that particular code in the component wok directory using input files as they existed before the call to the crashed binary. Basically a batch script that just executes the problematic code (the command used by the framework to execute the code can be found on the portal). It gets tricky when the component wrapper does more non-file based stuff before invoking the binary (e.g. set an env. var).

There's currently no way to just run the wrapper by itself (there are simply too many external dependencies that a wrapper as-coded relies upon to make this work out of the box).

dlg0 commented 9 years ago

OK, Thanks.

dlg0 commented 9 years ago

So what is the standard development workflow for an IPS wrapper - is it alter code, submit to queue, repeat?

Surely there is a way to dump the set of python commands the IPS does into each components work directory such that you can source a file then debug that wrapper without resubmitting a job?

elwasif commented 9 years ago

I would have to say that, short of the obvious testing of the underlying binary code using the inputs prepared by the wrapper, then the answer is no. Wrappers are meant to be used in conjunction with other wrappers, so there's a "state" in place when a wrapper method is invoked (either from a prior invocation to the same method, a prior invocation to another wrapper method, or prior invocation of methods from other components). Usually non-obvious errors come from conflicting updates to this global state. I don't know of a way to reliably capture all elements of this global state in a form that you can somehow feed a wrapper to replay a failed invocation.