Atomistic OVF file extension

[MSallermann]

Atomistic OVF file extension

To better support the atomistic use-case, it would be nice to extend the OVF file format by additional fields in the header.

The main problem with the current OVF format is that crystal lattices, consisting of a bravais lattice plus an additional basis cannot be efficiently modelled. They are neither rectangular nor is it necessary to explicitly save all of the positions in three extra columns. Therefore no of the possible meshtype values (rectangular orirregular) really fits.

I suggest to introduce meshtype lattice, which, if set, would require

• bravaisa a list of three values, giving the bravais vector in the first direction in terms of the meshunit
• bravaisb see above
• bravaisc see above
• anodes number of cells in direction a
• bnodes see above
• cnodes see above
• ncellpoints number of points per cell of the lattice

Lastly, one would need to save the basis vectors. About this part I am the least sure, since there seems to be no good precedent for how to format this in the OVF 2.0 spec.
A few options that come to mind:

## Option 1
# ncellpoints: 2
# basis:
# 0 0 0
# 0 1 0

## Option 2
# ncellpoints: 2
# basis: 0 0 0
# basis: 0 1 0

## Option 3
# ncellpoints: 2
# basis1: 0 0 0
# basis2: 0 1 0

## Option 4
# ncellpoints: 2
# basis: 0 0 0 0 1 0

Of all these, Option 4 breaks the previous OVF specification the least, but it's also the ugliest in my opinion. I would probably prefer Option 1 and thus allow multiline header fields.

One concern is of course the compatibility with the OVF 2.0 format, which unfortunately does not allow for the addition of arbitrary fields in the header.
I can imagine that it would be practicable to introduce a new file ending ".aovf" (for atomistic OVF).
Then I would implement a compatibility mode in this library, which would allow one to save (and read) AOVF files in a format that is compatible to OVF 2.0 (by prefixing the new fields with comments + some special character, e.g ##%).

Im not familiar with the pegtl library used here, so I am not sure how much of a hassle it would be to implement this.

A file in AOVF format could look like this:

# AOVF 1.0
#
# Segment count: 000001
#
# Begin: Segment
# Begin: Header
#
# Title: example.aovf
#
# Desc: more details in this comment...
#
# valuedim: 3   ## field dimensionality
# valueunits:   unspecified unspecified unspecified
# valuelabels:  unspecified unspecified unspecified
#
## Fundamental mesh measurement unit. Treated as a label:
# meshunit: unspecified
#
# meshtype: lattice
# xbase: 0
# ybase: 0
# zbase: 0
# bravaisa: 1 0 0
# bravaisb: 0 1 0
# bravaisc: 0 0 1
# anodes: 2
# bnodes: 1
# cnodes: 1
# ncellpoints: 2
# basis:
# 0 0 0
# 0.5 0 0
#
# End: Header
#
# Begin: Data Text
        0.000000000000        0.000000000000        0.000000000000
        3.000000000000        2.000000000000        1.000000000000
        0.000000000000        0.000000000000        0.000000000000
        0.000000000000        0.000000000000        0.000000000000
# End: Data Text
# End: Segment

And the same file in compatibility mode could look like this:

# OOMMF OVF 2.0
##% AOVF 1.0
#
# Segment count: 000001
#
# Begin: Segment
# Begin: Header
#
# Title: example.ovf
#
# Desc: more details in this comment...
#
# valuedim: 3   ## field dimensionality
# valueunits:   unspecified unspecified unspecified
# valuelabels:  unspecified unspecified unspecified
#
## Fundamental mesh measurement unit. Treated as a label:
# meshunit: unspecified
#
# meshtype: rectangular
# xbase: 0
# ybase: 0
# zbase: 0
# xstepsize: 1
# ystepsize: 1
# zstepsize: 1
# xnodes: 4
# ynodes: 2
# znodes: 1
##% bravaisa: 1 0 0
##% bravaisb: 0 1 0
##% bravaisc: 0 0 1
##% anodes: 2
##% bnodes: 1
##% cnodes: 1
##% ncellpoints: 2
##% basis:
##% 0 0 0
##% 0.5 0 0
#
# End: Header
#
# Begin: Data Text
        0.000000000000        0.000000000000        0.000000000000
        3.000000000000        2.000000000000        1.000000000000
        0.000000000000        0.000000000000        0.000000000000
        0.000000000000        0.000000000000        0.000000000000
# End: Data Text
# End: Segment

[GPMueller]

When this is implemented, it should be used to close issue #10.