<font size="4">Thank you very much for <font size="4">hints as to wh<font size="4">ich</font> <font size="4">way <font size="4">is the best to follow. It's great to see that e<font size="4">ven on Sunday I'm not left alone in the dark ;)</font><br>
<font size="4">I guess C++ external-program-friendly <font size="4">library won't be there anytime soon, so for now I'll have to<font size="4"> link e<font size="4">xternal executable to<font size="4"> libgmx</font> and produce file with required <font size="4">data extracted from <font size="4">input binary file</font>. <br>
<font size="4"><br><font size="4">Chris</font><br></font></font></font></font></font></font></font></font></font></font><br><div class="gmail_quote">2013/3/17 Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div class="im">On Sun, Mar 17, 2013 at 1:29 PM, Krzysztof Mlynarczyk <span dir="ltr"><<a href="mailto:mitomaster@gmail.com" target="_blank">mitomaster@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br><br>I have a similar problem with tpr files.<br>Linking to the gromacs library is fine as long as one wishes to write yet another typical analysis tool. <br>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.<br>
Now I see two solutions:<br><ol><li>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).<br>
</li><li>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.</li>
</ol>Or maybe there is a third option I don't see? What would you advise?</blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Mark</div></font></span></div>
<br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br>