Allow for more general properties to be saved by the generic calculator#355
Allow for more general properties to be saved by the generic calculator#355
Conversation
|
I'm happy with it, although in principle this is probably better handled using https://gitlab.com/ase/ase/-/blob/master/ase/outputs.py?ref_type=heads, as |
|
Let me have a look at outputs.py. And I really am only interested in polarization, for now, so let's skip |
|
There are some issues related to property |
|
Is it just #352? |
|
I think yes - this is what happens when I run pw.x in the CI |
|
working on a fix to |
|
@gelzinyte I just merged #358 into |
|
I think this looks better. Let's see how the tests go. |
|
Looks like these failures are probably real side effects of changes you're making. |
|
In the failing unit test no I think this change is small in practice and maybe even preferable? If you agree, I'd like to update the unit tests to also expect It's not a big change in how wfl functions will behave, because the generic calculator defaults to |
|
one of the docs examples also fails, let me have a look. |
I'm happy with updating the test to expect |
|
The examples' test was failing because the xtb calculator calculates |
In the
mainbranch, only the properties defined inper_atom_propertiesorper_config_propertiesare saved by the generic calculator, even if an extra property (e.g., "polarization" foraims) is among the calculator'simplemented_propertiesand in thecalculator.resultsdictionary. The change tries to save all of the properties requested from the calculator and the missing or not implemented properties are caught bycalc.get_property.