Skip to content
This repository has been archived by the owner on Sep 28, 2021. It is now read-only.

Reworked Default/Optional XML #413

Merged
merged 52 commits into from
Apr 15, 2020
Merged

Reworked Default/Optional XML #413

merged 52 commits into from
Apr 15, 2020

Conversation

baumeier
Copy link
Member

@baumeier baumeier commented Mar 31, 2020

Very first attempt at getting new default xml file behavior, testing on dftgwbse calculator:

  • full dftgwbse.xml file in share folder
  • calculator passes dftpackage options and gwbse options explicitly through, instead of the xml files
  • xml file reading only on calculator level

Still not good:

  • basisset, functional definitions are repeating
  • some tags are superfluous
  • xtp_tools still needs to be passed an user option file on the command line, which can be empty though

Fix #319

…tgwbse calculator:

- full dftgwbse.xml file in share folder
- calculator passes dftpackage options and gwbse options explicitly through, instead of the xml files
- xml file reading only on calculator level

Still not good:
- basisset, functional definitions are repeating
- some tags are superfluous
- xtp_tools still needs to be passed an user option file on the command line, which can be empty though
@ghost
Copy link

ghost commented Mar 31, 2020

DeepCode failed to analyze this pull request

Something went wrong despite trying multiple times, sorry about that.
Please comment this pull request with "Retry DeepCode" to manually retry, or contact us so that a human can look into the issue.

- basisset, auxbasisset, functional now given on base level
- dftgwbse.cc then transfers this into to both DFT and GWBSE options
- reporting removed, was not used at all
- archive file name now derived from XYZ file name
- XML output summary name now derived from XYZ file name
@JensWehner
Copy link
Member

I am not sure if all options should have a default, i.e. xyz file. Why do you want to default everything? I mean we can also put the xyz input into the xml file, if we want to reduce the number of files

@baumeier
Copy link
Member Author

baumeier commented Apr 1, 2020

The xyz input default does not hurt anyone. Adding the coordinates into the xml file is something I don't like. What people will always have is a coordinate file in most likely that format. Asking them to add xml tags around it is just going to be annoying for people.

And why defaulting everything? Just consider the minimum input file needed for orca
* xyzfile 0 1 system.xyz
It will do HF with def2-SVP.

@JensWehner
Copy link
Member

so orca does not default on the system.xyz as votca will do now.

@baumeier
Copy link
Member Author

baumeier commented Apr 2, 2020

Yes. We can "undefault" the xyz file name of course since a calculator as defined way down in tools or rather the application that xtpapplicaton is derived from strictly requires an optionfile to be supplied. Now in the full default case that would be a ridiculously looking thing like

<options>
<dftgwbse/>
</options>

If we require xyzfile to be specified, at least it will make sense to require the options file:

<options>
<dftgwbse>
<molecule>system.xyz></molecule>
</dftgwbse>
</options>

@junghans
Copy link
Member

junghans commented Apr 9, 2020

Merge after votca/votca#263

@junghans junghans changed the title [WIP] Reworked Default/Optional XML Reworked Default/Optional XML Apr 9, 2020
CHANGELOG.md Outdated Show resolved Hide resolved
@junghans
Copy link
Member

junghans commented Apr 9, 2020

It makes one test fail:

 230/244 Test #230: unit_test_orca .....................................***Failed    0.05 sec
 Running 5 test cases...
 Warning: VOTCASHARE environment variable not defined
 /builds/votca/votca/votca/xtp/src/tests/test_orca.cc(8634): error: in "orca_test/input_generation_version_4_0_1": check inp.substr(index1, index2 - index1) == "%basis\nGTOName =\"system.bas\";\nGTOAuxName =\"system.aux\";\n" has failed [%basis
 GTOName ="system.bas";
  != %basis
 GTOName ="system.bas";
 GTOAuxName ="system.aux";
 ]
 *** 1 failure is detected in the test module "orca_test"

@junghans junghans mentioned this pull request Apr 10, 2020
@codecov
Copy link

codecov bot commented Apr 11, 2020

Codecov Report

Merging #413 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff           @@
##           master    #413   +/-   ##
======================================
  Coverage    64.3%   64.3%           
======================================
  Files         281     281           
  Lines       23663   23663           
======================================
  Hits        15233   15233           
  Misses       8430    8430           
Flag Coverage Δ
#gcc 64.3% <0.0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8eecbfd...8eecbfd. Read the comment docs.

@junghans
Copy link
Member

@JensWehner please review! Do we need tests?

Copy link
Member

@JensWehner JensWehner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have two major concerns with this PR still

a) I do not get why we update the defaults with user options?
b) I am not sure, if it is a good idea to default everything.

@felipeZ
Copy link
Member

felipeZ commented Apr 14, 2020

I have two major concerns with this PR still

a) I do not get why we update the defaults with user options?

I think that updating the defaults with the user input is the normal behavior that I would expect of a general simulation package. As an author of a simulation package, you don't want all your users to enter every single variable for configuring all the details of your simulation neither force them to make a copy of the whole options file and manually update the sections that the user are interested in. Instead, most simulation packages allow the user to provide minimal input that is subsequently merged with the whole set of configuration variables.

b) I am not sure, if it is a good idea to default everything.

Put yourself on the user's shoes, you would like to try this amazing XTP package to do a DFT-GWBSE simulation, if instead of having a very simple input interface (that can be modified for expert users) you force your users to enter every single detail of the simulation, the potential users would run away ;)
Also, we want to interface with Python using ASE. The philosophy of those wrappers is "plug and play", meaning that a minimal configuration is required to make a given package to run which is very useful when doing scripting.

@JensWehner
Copy link
Member

Okay I agree with a).

Concerning b) I agree that most things can be defaulted, but inputfilenames should not be defaulted in my opinion.

@felipeZ
Copy link
Member

felipeZ commented Apr 14, 2020

Okay I agree with a).

How do you envision the input/defaults handling?

Concerning b) I agree that most things can be defaulted, but inputfilenames should not be defaulted in my opinion.

How shall we then handle the input filenames?

@JensWehner
Copy link
Member

I thought we do it the same way as before. I agree that 90% of all options have a sensible default, but I do not think that the coordinates file, or the output file have that.

@JensWehner
Copy link
Member

Apart from eanalyze and ianalzye I cannot see how you would default all options of a calculator.

@junghans
Copy link
Member

@JensWehner please review.

Copy link
Member

@JensWehner JensWehner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still do not think defaulting all options is a good idea, but the PR has a lot more good than bad things in it.

@junghans junghans merged commit c8fc9bd into master Apr 15, 2020
@junghans junghans deleted the defaults-xml branch April 15, 2020 01:42
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Default values to xml
4 participants