[CP2K:1574] Re: UNIT in &CELL and UNIT for output

[Teodoro Laino]

Hi Toon,

I understand your point of view. But....:

1) Creating a totally new standard would require a too huge effort.. and 
let me say that it does not pay back at the moment.
2) There is, still, the idea to borrow some more developed standard.. 
something similar to COST Q5 over hdf5.
But this is still an idea.
3) Putting a standardized header could be the way to go.. but the point 
is that the choice of the unit of measure for output quantities is 
supported for all formats (this means formatted and unformatted). and 
most of these formats do not accept an header, unless you don't break 
the format itself.
4) The idea of being able to choose the units of measure for output 
quantities is just HOT. This solves quite many issues, like the one of 
Ondrej and others in the past.

Having said all this.. I don't see any practical way of  working around 
the problem you mention, unless one works in a clean way (i.e. keeping 
track of all he is doing, with notes, README files and so).
Of course I'm totally opened to smart ideas which can be potentially 
used, without breaking the formats (XYZ, DCD and so).

A new standard, which would include all output + units, would seem the 
way to go.. but there is not human time available at the moment. Do you 
volunteer?

Cheers
Teo

Toon Verstraelen wrote:
> Hi Teo,
>
> Your efforts to get the dinosaurs out of the code are apreciated for sure. I'm a 
> bit worried about the configurable unit for the output files. This can be nasty, 
> e.g. when one has to post-process someone else's output files. Most of the times 
> this is a total disaster, certainly when I'm not totally sure about the units in 
> the output files.
>
> Are there plans for a standardized binary output format that contains all the 
> simulation data in a fixed unit, e.g. atomic units. This would avoid a lot of 
> misery. Another possible solution would be a standardized header that contains 
> the unit conventions used in the rest of the output file. The latter is maybe a 
> bit trickier? Are there any long term plans in this direction?
>
> cheers,
>
> Toon
>
>
> Teodoro Laino wrote:
>   
>> Dear All,
>>
>> A major rearrangement of the UNIT keyword in the CELL section was required.
>> The reason is that, the UNIT keyword was to be considered an old 
>> duplicate compared to the more
>> advanced way we can treat units (i.e. specifying them within square 
>> brackets []), and this was posing
>> severe issues, more technical (code specific) than user perspective.
>>  
>> Therefore this is how the code has been updated:
>> 1) UNIT keyword has been deleted from CELL section
>> 2) keyword A,B,C and ABC have now units (to specify a cell in bohr 
>> therefore is enough to
>>     input something like ABC [bohr] x y z)
>> 3) the units for the coord section can be specified now with two 
>> specific keywords in &COORD section
>>     COORD%UNIT  (by default angstrom)
>>     COORD%SCALED (by default set to FALSE)
>>     The first one accept a string (all units defined in CP2K can be 
>> input). The second one is a boolean.
>>     The units for the cell and for the coordinates have been now fully 
>> disentangled (you can use all kind
>>      of combinations you like)
>>
>> The sad part:
>> This change will break unavoidably all old input files, but the 
>> modifications to be done to make them compatible
>> with the new version are minor (just follow the few steps above).
>>
>> The innovation:
>> Moreover, since quite few people ask from time to time about units of 
>> output quantities, the last commit introduces, as well, the possibility 
>> to specify a unit of measure for quantities in output.
>> As you can imagine this would require a huge amount of work and the plan 
>> is to do it slowly.
>> Therefore at the moment very few print_key support the UNIT keyword. 
>> Possible requests to extend it
>> to other print_keys are well accepted and encouraged. All 
>> requests/comments can be posted on this thread.
>>
>> Luckily this should be one of the last dinosaurs in CP2K (i.e. there 
>> should not be other major changes
>> that break so deeply the compatibility between CVS shapshots).
>> My apologies for this inconvenience.
>> Teo
>>
>>     
>
>
>