Change system logic for Simulations: Conformance

[charlotte]

MOHC (Mark E)
Problem type: System Logic
Location: Simulations: Conformance

Is there anything we can do to make conformance easier to understand without redoing the database structure? CERFACS also had big problems with this - though they didn't have help text.

Not one of our team understood the process of creating and resolving inputs to establish conformance, all read the help text and road map material and were completely flumoxed. Some understanding after I demonstrated it, but probably not enough to do themselves without significant hand holding.

In the internal system we use (at the Met Office) I do everything from within the simulation - define the inputs and link them to a specific model/component in one place.

[bryan]

I'm not sure what we can do here, perhaps Charlotte, Mark and Bryan should have a brief telco.

[charlotte]

Comment from CERFACS:
The list of Needed (Resolved?) Inputs defined by the user appear in the "Input Bindings" Box of each Numerical Requirement. This is disappointing to the user who rather expect a list of Files (or Variables in Files). tricky concept: defining a "Needed Input" and "Resolving" it are 2 prerequisites before establishing a Conformance and establishing a Comformance consists in binging a "Numerical Requirement" to a "Resolved Input".

[charlotte]

I think users are confussed because Resloved Inputs is a "second order" concept.
In the first instance I believe we can help users to navigate conformance by ensuring that we use the same words for this concept throughout the questionnaire. When we talk about connecting inputs with variables and modifications we use all these terms:

• Input bindings
• Input couplings
• Resolved inputs
• Input Resolution

We can help users by coming up with a single term for this concept.

I propose we use the verb Unite.
The button would be labeled "Unite Inputs" and we can refer to the objects it creates as as "United Inputs". I don't like "Resolve inputs" because it leads us to talk about "input resolution" which is confusing because resolution usually means the spacing of the grid.

Once armed with a single name to describe this concept I think we can go a long way to helping users to understand what it means and what we want them to do with it.

[mariepierre]

Absolutely agree... to agree on a single term! This is a debate we had some times ago...

I reckon your argument against "Resoved"/"Resolution" but not convinced by "Unite"... Personally I found "binding" not so bad (don't worry I won't come back with "FulFilling" ;-)

Anyway, even if we ensure the wording consistency across the questionnaire (and we must do so), I'm not sure this will simplify enough the conformance which is a multiple-level concept...

[charlotte]

Questionnaire templates that contain the terms: input binding, input resolution, input coupling, input needed and input requirement (and their derivatives)

• componentMain.html
• coupling.html
• couplingform.html
• help.html
• inputs.html

[charlotte]

Tickets that will be fixed when we standardise the way we describe inputs

• #504
• #558
• #560

[charlotte]

Also ticket

• #503

[charlotte]

Bryan is making lots of changes to inputs in the questionnaire so I am going to hold off work on this ticket until after the beta2 release

[bryan]

So this is fixed in the lateChange (changeset:1957) branch so folks don't have to tie conformances to the inputs etc.