[gmx-developers] TPR parsing

[Krzysztof Mlynarczyk]

Thank you very much for hints as to which way is the best to follow. It's
great to see that even on Sunday I'm not left alone in the dark ;)
I guess C++ external-program-friendly library won't be there anytime soon,
so for now I'll have to link external executable to libgmx and produce file
with required data extracted from input binary file.

Chris

2013/3/17 Mark Abraham <mark.j.abraham at gmail.com>

>
>
> On Sun, Mar 17, 2013 at 1:29 PM, Krzysztof Mlynarczyk <
> mitomaster at gmail.com> wrote:
>
>> Hello,
>>
>> 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.
>
> Mark
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130317/3232a2aa/attachment.html>