[gmx-developers] TPR parsing
mark.j.abraham at gmail.com
Sun Mar 17 16:50:37 CET 2013
On Sun, Mar 17, 2013 at 1:29 PM, Krzysztof Mlynarczyk
<mitomaster at gmail.com>wrote:
> I have a similar problem with tpr files.
> Linking to the gromacs library is fine as long as one wishes to write yet
> another typical analysis tool.
> I'm writing an extension for another application and if the function from
> gromacs library calls gmx_fatal(), everything is getting killed while I'd
> like to tell the user that there was an error and wait for further
> instructions. I can do that with trajectories if I use libxdrfile package
> that returns error codes instead of exiting.
> Now I see two solutions:
> 1. Port tpr reading routines to libxdrfile and make them return error
> codes that can be checked and handled. This would be the most elegant
> solution but requires quite a bit of work (and subsequent maintenance to
> keep it in sync with current gmx version - but perhaps that could be
> automated with a script).
> 2. Write an external program that will be called with system()
> function and extracts the needed tpr data. Errors in it would not affect
> the extension and main application. This is the fastest way, but makes the
> plugin gromacs-dependent.
> Or maybe there is a third option I don't see? What would you advise?
If your license constraints permit it, you could bundle (some of) the
GROMACS source and just modify gmx_fatal() to do something more suitable.
That would make it easy to get control back, but not to transfer execution
from the point of the error to somewhere that can cope with it. So perhaps
not very useful.
Unfortunately, the GROMACS code is pretty much not designed to propagate
errors anywhere, since there's very few faults of which GROMACS can afford
to be tolerant. We'll do better with exceptions in 5.0. For now, I'd
encourage your second solution.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-developers