On Sun, Feb 5, 2012 at 4:28 PM, Chris Morley <c.mor...@gaseq.co.uk> wrote:
> On 05/02/2012 19:16, Ian Kirker wrote:
>> So, I've been working on a fuller Turbomole format reader (I won't
>> promise anything, I'm pretty new to proper C++ and it's probably going
>> to take me a Good While to get to finishing it if I do), but there are
>> two things Turbomole does which I felt might be an issue:
>>
>> 1) Turbomole input/output files are just called "control" -- you have
>> to run each separate Turbomole calculation in a separate directory,
>> and there's no file extension. I'm guessing this might be a problem
>> somewhere, but I'm not sure where.
>
>> 2) The "control" files can specify additional files where information
>> is, and this is critical for reading output, since while you do get an
>> output stream (which isn't directed to a file by default) the crucial
>> information for things like orbital rendering, SCF energies, and
>> vibrational modes are stored back in segments of the control file/s.
>>
>> Now, I've written (functional but not really danger-proof) code to
>> find and retrieve the data to handle (2), but I wanted to check
>> whether opening extra files was viewed as a legitimate activity for
>> format reading plugins to perform before I went any further, so I'd
>> welcome opinions on this, or a link to a document containing what
>> format plugins should and shouldn't do if there's one.
>
> Although I'm not familiar with it, vaspformat seems to use a specified
> directory to open multiple input files in the way you suggested. It
> might be more difficult if you wanted to read more than one set of input
> files, because OpenBabel can use a queuing system when converting
> multiple molecules.
Yes, the VASP format needs something similar. The main problem I ran
into with it is that OB is designed to best work with streams, not
necessarily files, and getting it to work properly took a bit of work
and has some "gotchas". I've put them into the description of the VASP
format. Specifically, (1) OBConversion::ReadFile must be used instead
of the other methods, and (2) The complete path to the main output
file must be supplied. You'll probably have to do something similar
with the writing process to get the path information to the format
writer.
> A file extension is not needed. When the format is used in OBConversion
> in C++ etc. it needs to be explicitly specified and on the commandline
> the -o option is used.
Or if the filename is consistent, you can register it with the plugin
system. For instance, VASP uses:
OBConversion::RegisterFormat("CONTCAR",this);
to open files named CONTCAR automatically. If there's a conflict with
another file format for the "control" filename, something like
outformat.cpp could be added.
Dave
> Apart from exampleformat.cpp, I don't think there is any other
> documentation on writing formats.
>
> Chris
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
