Gravity Proposal

[rrsettgast]

Currently there is a gravity vector in the top level solvers block, of which each individual solver will inherit, although it is possible to specify a gravity vector in each individual solver rather than inherit from the top level. On top of that there are things like the gravityFlag option that turns on and off gravity for a flow solver.

Questions/proposals:

1. The gravityFlag option is redundant. If you want to turn off gravity, you can set the gravity vector zero. What would everyone think about getting rid of the gravityFlag?

2. The ability to have different gravity vectors floating around can cause a bit of confusion. Do we really want different gravity vectors for each solver? In a coupled problem, do we really want to be able to turn off gravity for one physics package, but not the other? I.e. what sense does having gravity off for a flow solver when the mechanics solver has gravity? or vice-versa? Should we just have a single gravity vector for the entire problem or should we maintain the flexibility to change the gravity vector for a solver? This means that you get the single gravity vector unless you specify a separate one in an individual solver (what we have now).

[klevzoff]

1. Agree, it's redundant. As a minor consideration, we could get a slightly better memory bandwidth utilization if we avoided accessing gravDepth (and density averaging) in flux assembly kernel when gravity is switched off. In that case, we could just have the flag set internally (not exposed to input) based on gravityVector being zero/nonzero.
2. I don't see a need for separate gravity vectors either. Or at least I don't have a good argument for it.

[joshua-white]

1. Agree, totally redundant
2. Separate gravity vectors seem odd to me too.

Just as another option for discussion, we could simplify and just have as the input parameter gravity={on, off}. I don't see a real problem with the convention that the z-axis is vertical and we live on earth. Such fine-grained user control of the gravity vector seems like overkill. We then need to carry around a vector in all our solvers, where all we really need is the scalar gravitational constant.

I suspect I will lose this argument though :-)

[joshua-white]

On a related topic, we should also have a discussion about how we want to deal with setting initial equilibrium conditions. That is, how does one specify the initial stress, pore-pressure gradient, fracture tractions, etc. There are a variety of ways to approach this, with advantages and disadvantages. Perhaps a discussion for the developer meeting ...

[francoishamon]

In my opinion, it is more error-prone to let the user set the gravity vector. In particular, the minus sign can possibly create some confusion, since I think the orientation (upward or downward) of the z-coordinate is a convention that can change from one code to the other. So, I am also in favor of just having an input parameter gravity={on,off}, and then documenting the gravity vector (convention used, value, etc) in the user documentation and in the code.

[klevzoff]

I see no problem with just a binary parameter. But there needs to be a single place in code where physical constants are defined.

(Just wait until people start drilling on Moon or Mars :wink:)

[joshua-white]

My money is on hydrogen processing in the Jovian atmosphere.

[rrsettgast]

OK. How about this. At the top level we support two entries:

<Problem>
    <Solvers 
        applyGravity="0/1" <------ default to off?
        gravityVector="0.0,0.0,-9.81"  <----default value so this is optional
        >

        <SinglePhaseFlow
            ...
        </SinglePhaseFlow>

    </Solvers>
</Problem>

The gravityVector will have a default value as shown, so it will typically not need to be specified. SolverBase will have member functions applyGravity() and gravityVector() that get these values from the top level. Thus all physics solvers will have the same value and application of gravity will be uniform for the problem. We document the default value of gravityVector as @francoishamon suggests, and mention that the value can be changed for power users. But in practice, the standard usage will just be to specify the binary value of applyGravity.

What should the value of gravityVector be? I would say 1 or on.

[herve-gross]

I would recommend the default value of applyGravity to be on (not off). It is also more explicit than 0/1.