VTT-ProperTune / OpenPFC

Open-source solver for phase field crystal type (PFC) type problems.
GNU Affero General Public License v3.0
9 stars 4 forks source link

Add option to add initial and boundary condition to fields with different names #42

Open ahojukka5 opened 9 months ago

ahojukka5 commented 9 months ago

At the moment, support for multiple fields works only partially. They can be defined in model, but it's not possible to define any initial or boundary condition to other fields than default. Some modifications is needed, probably backward incompatible ones.

Description

Currently, we define initial and boundary conditions to fields in json file in this way:

    "initial_conditions": [
        {
            "type": "constant",
            "n0": -0.10
        },
        {
            "type": "seed_grid",
            "X0": 30.0,
            "Ny": 2,
            "Nz": 2,
            "radius": 25.0,
            "amplitude": 0.215936,
            "rho": -0.047
        }
    ],
    "boundary_conditions": [
        {
            "type": "moving",
            "rho_low": -0.464,
            "rho_high": -0.10,
            "width": 15.0,
            "alpha": 1.0,
            "disp": 40.0,
            "xpos": 127.17225402106772
        }
    ]

Like can seen, there is no any way to give option to which field these should be affected. Historically, we started with a field phi which was given by get_field, and later on it was extended that we can get any field by giving it's name, like get_field("myfield"). To preserve backward compatibility, we default to a field called default. For example, here we get the field inside boundary condition:

    const Decomposition &decomp = m.get_decomposition();
    Field &field = m.get_field();  // <-- defaults to m.get_field("default") !!
    const World &w = m.get_world();
    Vec3<int> low = decomp.inbox.low;
    Vec3<int> high = decomp.inbox.high;

There is no information on boundary condition / initial condition (a.k.a. "field modifier") to which field it should operate, and this needs to be changed. Perhaps introduce std::string m_field_name, some getter const std::string &get_field_name() const and things like that. So we can still add default field name default to member variable in order to maintain backward compatibility. Those need to be implemented to FieldModifier.

Then, in json file, we might have something like target or field_name which determines what field to operate on, and if not given, default:

        {
            "name": "phi",
            "type": "moving",
            "rho_low": -0.464,
            "rho_high": -0.10,
            "width": 15.0,
            "alpha": 1.0,
            "disp": 40.0,
            "xpos": 127.17225402106772
        }
ahojukka5 commented 9 months ago

This is now partially implemented:

{
    // ...
    "fields": [
        {
            "name": "psi",
            "data": "/data/pfc/tungsten/psi_%d.bin"
        },
        {
            "name": "psiMF",
            "data": "/data/pfc/tungsten/psimf_%d.bin"
        }
    ],
    "initial_conditions": [
        {
            "target": "psi", // <-- target
            "type": "constant",
            "n0": -0.4
        },
        {
            "target": "psi", // <-- target
            "type": "single_seed",
            "amp_eq": 0.215936,
            "rho_seed": -0.047
        }
    ],
    "boundary_conditions": [
        {
            "target": "psi",  // <-- target
            "type": "fixed",
            "rho_low": -0.464,
            "rho_high": -0.100
        }
    ]
}

It however defaults to real fields as shown e..g here.