Minimum availability constraint.

[ajpearcey]

As noted in #297

The new availability model is working, but as yet it doesn't really depend much on the design, as was intended. Consequently
constraint 61 (Minimum availability value) doesn't really work very well - either the availability is adequate, or it isn't, in which case
VMCON will probably fail.

We could add a few iteration variables to rectify this.

This constraint (icc = 61) is not commonly used. But, the main point raised in the original issue is still true even with the newer availability models included in process, but we would need to think about how and if we what to modify these to work better with the minimum availability constraint.

[mkovari]

The original idea for the availability model implemented by James came from Richard. He suggested that whenever an engineering quantity gets too close to its permissible limit, things are more likely to fail and will need to be replaced more often.

While this is true, the main factors determining availability are:

• Neutron flux
• Material resilience to irradiation
• Activity resulting from irradiation
• Decay time required between plasma operation and maintenance
• Radiation hardness of remote handling equipment
• Speed and sophistication of remote handling equipment.

Only one of these is included in PROCESS: neutron flux.

We could add a few iteration variables to rectify this.

I really don't know what I meant by this.

Availability is a critical input when calculating cost of electricity, so we still need it. My suggestion is to shelve sophisticated models and return to a very simple formula that takes a few inputs:

• life of divertor,
• life of blanket,
• decay time,
• time to replace one divertor module,
• time to replace one blanket module
• reactor lifetime.

This is not that different from the Taylor and Ward iavail = 1 model.