Personal tools
You are here: Home / cmgui / Wiki / Single Field List
Navigation
Log in


Forgot your password?
 

Single Field List

Withdrawn Proposal: Share single field list across multiple regions

_NOTE_ I'm keeping this page for archive purposes, but replace it with proposal Fields Owned By Region.

Regions currently have independent lists of FE_fields: field coordinates in the root_region has no formal connection with field coordinates in region /heart, and they may have different definitions (coordinate system, number of components etc.)

The single Computed field manager monitors FE_fields in the root_region and automatically wraps them in a Computed_field_finite_element. Fields in subregions are not wrapped and are therefore inaccessible to most of the program. Exception: since compare_FE_field is just strcmp of the field name, it is possible for e.g. computed field coordinates to be evaluated on a child region; in the case of the prolate heart it may be presented in the wrong coordinate system.

To enable effective use of subregions, it is proposed that the master FE_field list from the root_region be shared throughout all sub-regions (by default).

  1. What happens if attempting to merge prolate coordinates field in heart into RC parent region?
Instead of causing a merge to fail, incompatible fields can be given an automatic name change to indicate the difference, e.g. prolate_coordinates for different coordinate system, or coordinates2 if different numbers of components. Reasons for using a prolate-spheroidal coordinate system (to minimise DOFs) are no longer significant, so this case has little importance.
  1. How does a new region inherit field definitions?
Supply APIs for creating regions as children of existing regions to inherit fields, shapes and bases.
  1. Can we support both shared and separate field definitions?
Proposal is only that the default behaviour is to share field definitions: no reason why we can't have multiple field namespaces (and share these over different parts of the hierarchy) at any time. Still need to work out how to synchronise new field namespace with the single Computed_field manager.
  1. Were alternative implementations considered?
An earlier idea was to declare every field in every region separately and provide structures to link equivalent fields across the hierarchy, to enable arbitrary transformations and clever hierarchical operations. This is exceedingly complicated and infeasible to implement. With the proposal to use 4x4 matrix transformations of coordinate spaces between regions (see Merge Regions And Scenes), one of the few benefits mooted for it, easy transformation of fields into other regions' spaces (e.g. to help correlate model with texture) can be easily replaced by a computed field that maps coordinate systems from one region path to another.
  1. Are any nice features missing from the proposed change?
It would be nice to permit different representations of the same field in different regions, for example, constant on one and spatially varying on another. Such changes are left to FieldML.

Feedback

Please add any feedback here

Shane: How about trying not to spread FE_fields any further through the
program. The FE_fields could remain private and localised and the name changes or transformations handled as these are wrapped. I guess in philosophy I'm trying to hide FE_fields from users and from the API, I kind of hope that we don't have to expose it anywhere.
Shane: I feel that only allowing 4x4 transformations of field coordinates
between regions is arbitrary and not what we generally use, instead we tend to have embedded meshes. I'll wait to see the merge scenes page before commenting further.

Shane: Otherwise this sounds a pragmatic improvement.

Richard: Between writing this and Merge Regions And Scenes I've changed my thinking about transformations, leaving 4x4 matrix transformations as a purely graphical concept. An FE_region lives in its own space; we can consider transformations between fields in regions once a concrete application and requirements appear.

Richard: The ideal is for FE_fields to remain private to their FE_region, and able to differ in certain ways (different coordinate system, spatially varying or not) yet still wrapped by a common computed field which presents the external interface to the field (and ensures consistent coordinate system). We can match by name; but do we need other facilities to match fields without the same name? Needs more thinking. See also: http://www.cmiss.org/cmgui/tracker/623