I’ve performed some refactorization of inputfileextension - now all dialogs (including even Gamess one) are derived from the same base class InputDialog and use common function for file saving (excluding Gaussian, which needs a trick with checkpoint file name; however I think this solution is a crutch). I’ve removed some other code duplications too.
However, I can’t test running of Gaussian and MOPAC from Avogadro (more precisely, use cases of readOutput signal. Please, test it if you merge my trunk
On Thu, May 13, 2010 at 12:21:15PM +0400, Konstantin Tokarev wrote:
However, I can’t test running of Gaussian and MOPAC from Avogadro
(more precisely, use cases of readOutput signal. Please, test it if
you merge my trunk –
BTW, for MOPAC, it would be nice if MOPAC7 (the public domain version) would
be supported as well.
However, I can’t test running of Gaussian and MOPAC from Avogadro
(more precisely, use cases of readOutput signal. Please, test it if
you merge my trunk –
BTW, for MOPAC, it would be nice if MOPAC7 (the public domain version) would
be supported as well.
On Thu, May 13, 2010 at 06:33:35PM +0400, Konstantin Tokarev wrote:
However, I can’t test running of Gaussian and MOPAC from Avogadro
(more precisely, use cases of readOutput signal. Please, test it if
you merge my trunk –
BTW, for MOPAC, it would be nice if MOPAC7 (the public domain version) would
be supported as well.
I’ve never worked with MOPAC, so I can’t help
Hrm, it looks like the differences are (at least) as follows:
Does not understand the AUX keyword, it should be ommitted
The PM6 and RM1 methods are not available
The NOOPT keyword should be ommitted when no optimization is desired
I am not sure whether it makes more sense to have a switch in the MOPAC
extension to change between Mopac2000 and Mopac7 output, or having two
seperate extensions.
Mid-term it is maybe possible to unify all input generators in one
dialog and just have a multi-select for the desired program. I believe
most options are shared by most generators, and some can be left
out/greyed out.
By the way, the Mopac extensions spells out the multiplicity as
“Singlet, Doublet” etc., while all other have a numeric spin-button (at
least in 1.0.1). Using the spelled out version for the others as well
might be nicer.
On Thu, May 13, 2010 at 06:33:35PM +0400, Konstantin Tokarev wrote:
However, I can’t test running of Gaussian and MOPAC from Avogadro
(more precisely, use cases of readOutput signal. Please, test it if
you merge my trunk –
BTW, for MOPAC, it would be nice if MOPAC7 (the public domain version) would
be supported as well.
I’ve never worked with MOPAC, so I can’t help
Hrm, it looks like the differences are (at least) as follows:
Does not understand the AUX keyword, it should be ommitted
The PM6 and RM1 methods are not available
The NOOPT keyword should be ommitted when no optimization is desired
I am not sure whether it makes more sense to have a switch in the MOPAC
extension to change between Mopac2000 and Mopac7 output, or having two
seperate extensions.
For Molpro, I’ve added combo box to generate input for 2009 or earlier versions (geometry and symmetry syntax slightly differ). I think it’ll be fine for Mopac too.
Mid-term it is maybe possible to unify all input generators in one
dialog and just have a multi-select for the desired program. I believe
most options are shared by most generators, and some can be left
out/greyed out.
By the way, the Mopac extensions spells out the multiplicity as
“Singlet, Doublet” etc., while all other have a numeric spin-button (at
least in 1.0.1). Using the spelled out version for the others as well
might be nicer.
Hrm, it looks like the differences are (at least) as follows:
Does not understand the AUX keyword, it should be ommitted
The PM6 and RM1 methods are not available
The NOOPT keyword should be ommitted when no optimization is desired
One catch is that the MO reading for MOPAC uses the AUX files. I’m not sure Jimmy Stewart ever documented how you’re supposed to read MO information from MOPAC7. I know it’s possible, but Avogadro doesn’t have the code yet. If someone can find code for reading orbitals, that would be helpful.
As far as versions, It should be possible to detect the MOPAC version with a small test input.
Mid-term it is maybe possible to unify all input generators in one
dialog and just have a multi-select for the desired program.
Hmm. This might benefit the “basic/advanced” split I’d like to see as far as the input generators. For example, the Avogadro “core team” provides some “basic” generators like the current ones. This would probably include a basic GAMESS or Firefly dialog. Then other more “advanced” extensions can be provided by others – and we can push out the currently unmaintained GAMESS code to an external extension.
By the way, the Mopac extensions spells out the multiplicity as
“Singlet, Doublet” etc., while all other have a numeric spin-button (at
least in 1.0.1). Using the spelled out version for the others as well
might be nicer.
Good point.
Thanks,
-Geoff
P.S. One thing I’ve wanted to do for the input generators is to read a user’s bashrc or similar and use that environment. On Mac, or on Linux launch from a desktop shortcut, we may not inherit the right paths or environment variables to find or run programs. So we’d run a process to generate the user-interactive environment, then use QProcess:setProcessEnvironment for our call to Gaussian or MOPAC, etc.
Mid-term it is maybe possible to unify all input generators in one
dialog and just have a multi-select for the desired program.
Hmm. This might benefit the “basic/advanced” split I’d like to see as far as the input generators. For example, the Avogadro “core team” provides some “basic” generators like the current ones. This would probably include a basic GAMESS or Firefly dialog. Then other more “advanced” extensions can be provided by others – and we can push out the currently unmaintained GAMESS code to an external extension.
I absolutely agree that Gamess dialog ui is the best. I also like it’s abstraction of InputData. It’s main disadvantage is absolute following Gamess input data structure.
My ideas:
Probably it’s possible to move more stuff into abstract InputDialog class.
Keep Gamees extension mostly intact. Draw new “universal” ui form containing two tabs (basic and advanced) looking like Gamess one. This ui will be protected member of InputDialog class and available for all subclasses
Use code generation for input dialog classes
Explanation:
Every QC package has certain list of “features”: supported basis sets, methods, variations of methods (e.g., for dft - list of available functionals, for CC - list of higher available order and local variants, available variations of CI)
Than, some methods are available for RHF reference only, other for ROHF or UHF (e.g., NWChem can do CC on UHF reference) - it should be taken into account. Also we need to specify what basis sets/methods are present in basic tab.
As for me, the most natural way to resemble pecularities of QC software is XML description and code generation. Goal is to generate C++ class (header and source) which will
a) inherit InputDialog
b) fill combo boxes in UI with list of basis sets etc
c) enabled/disabled additional configuration “leafs” in common UI, set up connections
I’ve written little sample of C++ header generator in XSLT, major drawback is a horrible language I can send it later, if you’re interested. Maybe you know better way to get C++ from XML?
If generator still needs to have additional leafs in dialog, xslt-generated class could be inherited (the same way we inherit Ui’s made by uic).
Mid-term it is maybe possible to unify all input generators in one
dialog and just have a multi-select for the desired program.
Hmm. This might benefit the “basic/advanced” split I’d like to see as far as the input generators. For example, the Avogadro “core team” provides some “basic” generators like the current ones. This would probably include a basic GAMESS or Firefly dialog. Then other more “advanced” extensions can be provided by others – and we can push out the currently unmaintained GAMESS code to an external extension.
I absolutely agree that Gamess dialog ui is the best. I also like it’s abstraction of InputData. It’s main disadvantage is absolute following Gamess input data structure.
My ideas:
Probably it’s possible to move more stuff into abstract InputDialog class.
Keep Gamees extension mostly intact. Draw new “universal” ui form containing two tabs (basic and advanced) looking like Gamess one. This ui will be protected member of InputDialog class and available for all subclasses
Use code generation for input dialog classes
Explanation:
Every QC package has certain list of “features”: supported basis sets, methods, variations of methods (e.g., for dft - list of available functionals, for CC - list of higher available order and local variants, available variations of CI)
Than, some methods are available for RHF reference only, other for ROHF or UHF (e.g., NWChem can do CC on UHF reference) - it should be taken into account. Also we need to specify what basis sets/methods are present in basic tab.
As for me, the most natural way to resemble pecularities of QC software is XML description and code generation. Goal is to generate C++ class (header and source) which will
a) inherit InputDialog
b) fill combo boxes in UI with list of basis sets etc
c) enabled/disabled additional configuration “leafs” in common UI, set up connections
I’ve written little sample of C++ header generator in XSLT, major drawback is a horrible language I can send it later, if you’re interested. Maybe you know better way to get C++ from XML?
If generator still needs to have additional leafs in dialog, xslt-generated class could be inherited (the same way we inherit Ui’s made by uic).
Oh, I’ve forgotten about major thing - inheritance from generated class will be required for at least one function - generation of text stream, using standardized data structures filled in generated class. It’s not possible to store this algorithm inside XML
On May 13, 2010, at 12:50 PM, Konstantin Tokarev wrote:
As for me, the most natural way to resemble pecularities of QC software is XML description and code generation. Goal is to generate C++ class (header and source) which will
a) inherit InputDialog
b) fill combo boxes in UI with list of basis sets etc
c) enabled/disabled additional configuration “leafs” in common UI, set up connections
I’ve written little sample of C++ header generator in XSLT, major drawback is a horrible language I can send it later, if you’re interested. Maybe you know better way to get C++ from XML?
So here’s the thing – we can use QML files for much of the interface. So maybe we have our own XML description which gets transformed into QML and any C++ stubs needed.
I wouldn’t use XSLT. It’s horrible. There’s more than one way to get there! I’d suggest we write a Python script which parses the XML description and writes out needed source files.
On May 13, 2010, at 12:50 PM, Konstantin Tokarev wrote:
As for me, the most natural way to resemble pecularities of QC software is XML description and code generation. Goal is to generate C++ class (header and source) which will
a) inherit InputDialog
b) fill combo boxes in UI with list of basis sets etc
c) enabled/disabled additional configuration “leafs” in common UI, set up connections
I’ve written little sample of C++ header generator in XSLT, major drawback is a horrible language I can send it later, if you’re interested. Maybe you know better way to get C++ from XML?
So here’s the thing – we can use QML files for much of the interface. So maybe we have our own XML description which gets transformed into QML and any C++ stubs needed.
I’ve looked at it. But it doesn’t provide any capabilities which are not related to GUI. And GUI it this case is the leeast of evils - we can draw many widgets for separate “leafs” and them disable individual elements in generated classes. (it’s not very extensible approach though)
I wouldn’t use XSLT. It’s horrible.
Yeah. Even PHP seems to be much more powerful for this task. Problem is easy access to XML elements
There’s more than one way to get there! I’d suggest we write a Python script which parses the XML description
The only thing I’ve liked in XSLT (never worked with it earlier) is how easy are XML elements accessed. Can it be done easily from Py?
So maybe we have our own XML description which gets transformed into QML and any C++ stubs needed.
UI generation seems to be not very reliable for me because it’s important to have an ability to edit UI visually.
I’ve thought about incorporation of xslt statements into .ui file (XSLT is born to generate XML, not C++!), but I think Designer will strip out them after edit (didn’t verified though). The same thing may occur with QML or worse if Designer will not eat our variables inside QML)
On May 13, 2010, at 1:20 PM, Konstantin Tokarev wrote:
So here’s the thing – we can use QML files for much of the interface. So maybe we have our own XML description which gets transformed into QML and any C++ stubs needed.
I’ve looked at it. But it doesn’t provide any capabilities which are not related to GUI. And GUI it this case is the leeast of evils - we can draw many widgets for separate “leafs” and them disable individual elements in generated classes. (it’s not very extensible approach though)
I’m not saying that QML will do everything we might want in this case, but I suspect we can generate a variety of QM input extensions using XML → QML transformations.
The only thing I’ve liked in XSLT (never worked with it earlier) is how easy are XML elements accessed. Can it be done easily from Py?
So here’s the thing – we can use QML files for much of the interface. So maybe we have our own XML description which gets transformed into QML and any C++ stubs needed.
I’ve looked at it. But it doesn’t provide any capabilities which are not related to GUI. And GUI it this case is the leeast of evils - we can draw many widgets for separate “leafs” and them disable individual elements in generated classes. (it’s not very extensible approach though)
I’m not saying that QML will do everything we might want in this case, but I suspect we can generate a variety of QM input extensions using XML → QML transformations.
OTOH, if we implement loading of external QML, users wil be able to create input generators for their favourite software easily and redistribute without any difficulties…
The only thing I’ve liked in XSLT (never worked with it earlier) is how easy are XML elements accessed. Can it be done easily from Py?
OTOH, if we implement loading of external QML, users wil be able to create input generators for their favourite software easily and redistribute without any difficulties…
Keep in mind that we’re talking about the UI. Speed is less important there, since we humans are slow compared to modern CPUs. But QML is an extension to JavaScript. So the “overhead” is the transformation of QML to compiled JavaScript like loading a webpage. I think if we can get as much into the QML as possible, it will be an important benefit. Consider that the QML will run on Mac, Windows, Linux with no compiler issues.
I like XPath approach
Sure. As I said, there are multiple ways to handle this. One benefit of the XML option description approach is that people can include more tooltips generated from user manuals. Q-Chem has a nice example of this in their QUI extension.
OTOH, if we implement loading of external QML, users wil be able to
create input generators for their favourite software easily and
redistribute without any difficulties…
Keep in mind that we’re talking about the UI. Speed is less important
there, since we humans are slow compared to modern CPUs. But QML is
an extension to JavaScript. So the “overhead” is the transformation
of QML to compiled JavaScript like loading a webpage. I think if we
can get as much into the QML as possible, it will be an important
benefit. Consider that the QML will run on Mac, Windows, Linux with
no compiler issues.
If we talk about current state of QC generators (several generators
included into source tree, no 3rd party), I think it would be a bit
more reasonable to have them compiled natively. If we want to load
external QML, situation is different
On Thursday 13 May 2010 04:21:15 Konstantin Tokarev wrote:
I’ve performed some refactorization of inputfileextension - now all dialogs
(including even Gamess one) are derived from the same base class
InputDialog and use common function for file saving (excluding Gaussian,
which needs a trick with checkpoint file name; however I think this
solution is a crutch). I’ve removed some other code duplications too.
However, I can’t test running of Gaussian and MOPAC from Avogadro (more
precisely, use cases of readOutput signal. Please, test it if you merge my
trunk
Sounds great - I have been wanting to do this for quite some time, but lacked
the time to do it. They share a great deal, differing mainly in options and the
text output. I think Geoff has a point though, QML looks very promising for
generating these documents, possibly giving users the power to add and change
these easily.
I wrote most of the MOPAC code, and at the time was using AUX because it was
well documented. I think there is a somewhat documented format for the public
domain version, but without the AUX file no orbitals will be read in. I don’t
have access to all of these codes directly anymore, but I think this is a
great direction to go in with these dialogs.
I think that the advanced dialogs tend to diverge and specialize much more
though, and look at QUI and GAMESS as examples of them.
On Thursday 13 May 2010 04:21:15 Konstantin Tokarev wrote:
I’ve performed some refactorization of inputfileextension - now all dialogs
(including even Gamess one) are derived from the same base class
InputDialog and use common function for file saving (excluding Gaussian,
which needs a trick with checkpoint file name; however I think this
solution is a crutch). I’ve removed some other code duplications too.
However, I can’t test running of Gaussian and MOPAC from Avogadro (more
precisely, use cases of readOutput signal. Please, test it if you merge my
trunk
Sounds great - I have been wanting to do this for quite some time, but lacked
the time to do it. They share a great deal, differing mainly in options and the
text output. I think Geoff has a point though, QML looks very promising for
generating these documents, possibly giving users the power to add and change
these easily.
I wrote most of the MOPAC code, and at the time was using AUX because it was
well documented. I think there is a somewhat documented format for the public
domain version, but without the AUX file no orbitals will be read in. I don’t
have access to all of these codes directly anymore, but I think this is a
great direction to go in with these dialogs.
I think that the advanced dialogs tend to diverge and specialize much more
though, and look at QUI and GAMESS as examples of them.
… and code generation will serve this much better than inheritance
If one wants more specialized controls, I think it would be reasonable to inherit generated stuff and add more, and for UI, add new configuration “leaf”
Returning to the topic: could you test, does everything work properly after my changes? I’ve tested only deck export
I can send it later, if you’re interested. Maybe you know better way to get C++ from XML?