Module ANY FACET

it is not clear what the extend signature should be for maximum combined generality and efficiency.

Member fiber_bundle::at3::component (int xi, int xj, int xk) const

This really belongs in at3_e3. Should we put it there?

Member fiber_bundle::at3_lite::component (int xi, int xj, int xk) const

This really belongs in at3_e3. Should we put it there?

Member fiber_bundle::atp_algebra::star (const e2 &x0, e2 &xresult, bool xauto_access)

Do these functions belong in e2?

Class fiber_bundle::base_space_crg_interval

this class really should be named homogeneous_block_crg_interval.

Member fiber_bundle::base_space_member::invariant () const

what are the invariants for this class

how do we enforce the invariance(nae space is fiber bundles)?

Member fiber_bundle::bilinear_2d::integrate (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf, const dof_type xintegrands[], size_type xintegrands_ub, value_type xresult_integrals[], size_type xresult_integrals_ub)

Interpreting the number of integrands per node as xintegrands_ub/xresult_integrals_ub.

Member fiber_bundle::bilinear_2d::jacobian (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf, const dof_type xlocal_coords[], size_type xlocal_coords_ub)

This can probably be made more efficient by reordering /// the loops.

Member fiber_bundle::binary_section_dof_iterator::update_item ()

resets host, which is unnecessary except when called from reset_item. Would be more efficient to just reset indices; avoids call to _item.init_handle_data_members

Member fiber_bundle::binary_section_space_schema_member::attach_to_state (const section_space_schema_poset *xhost, pod_index_type xbase_space_id, pod_index_type xfiber_schema_id)

what are the dof subposets?

Member fiber_bundle::binary_section_space_schema_member::attach_to_state (pod_index_type xbase_space_id, pod_index_type xfiber_schema_id)

what are the dof subposets?

Member fiber_bundle::binary_section_space_schema_member::invariant () const

what are the invariants for this class

Member fiber_bundle::binary_section_space_schema_poset::new_state (const poset_path &xpath, const schema_poset_member &xschema, array_poset_dof_map &xdof_map)

the following is unexecutable because dof maps don't have a schema until attached to a host; requires covariant schema feature to implement.

Member fiber_bundle::constant_eval_family::initialize (const namespace_poset &xname_space)

Should the compound types be represented separately? Evaluator_family is supposed to support the notion of a map from a local cell to an evaluator on that local cell. The compound cell types, e.g. triangle_nodes and triangle_complex, are exactly the same type of local cell as triangle. They probably should have the same cell type id and not appear separately in this table.

Member fiber_bundle::deep_size (const chart_point_1d &xp, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const chart_point_2d &xp, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const chart_point_3d &xp, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const differentiable_section_evaluator &xe, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const discretization_context &xc, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const e3_lite &x0, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const integrable_section_evaluator &xe, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const sec_tuple &x0, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const sec_vd &x0, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const section_evaluator &xe, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::deep_size (const structured_block &x0, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member fiber_bundle::dlinear_eval_family::initialize (const namespace_poset &xname_space)

Should the compound types be represented separately? Evaluator_family is supposed to support the notion of a map from a local cell to an evaluator on that local cell. The compound cell types, e.g. triangle_nodes and triangle_complex, are exactly the same type of local cell as triangle. They probably should have the same cell type id and not appear separately in this table.

Member fiber_bundle::ed_algebra::normalize (const ed &x0, ed &xresult, bool xauto_access)

Do we just want to do nothing if the length of the vector is zero?

Member fiber_bundle::ed_algebra::normalize (const ed_lite &x0, ed_lite &xresult)

Do we just want to do nothing if the length of the vector is zero?

Member fiber_bundle::ed_algebra::put_length (ed &x0, const vd_value_type &xlength, bool xauto_access)

Do we just want to do nothing if the length of the vector is zero?

Member fiber_bundle::ed_algebra::put_length (ed_lite &x0, const vd_value_type &xlength)

Do we just want to do nothing if the length of the vector is zero?

Member fiber_bundle::fiber_bundles_namespace::make_base_space_member_prototypes (base_space_poset *xspace)

Should the compound types be represented separately? The type_id is supposed to support the notion of alocal cell type, i.e. a particular geometric shape. The compound cell types, e.g. triangle_nodes and triangle_complex, are exactly the same type of local cell as triangle. They probably should have the same cell type id.

Member fiber_bundle::gl2::gl2 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::gl3::gl3 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::gln::make_standard_schema (namespace_poset &xns)

: The relationship of the dof schema declarations to the dof order is totally opaque. We need to somehow clarify this.

Member fiber_bundle::gln_lite::table_dofs () const

Where do these c_strings get deleted?

Member fiber_bundle::inverse (const gl2_lite &xlite, gl2_lite &xresult)

What do we want to do here? If the component matrix is already the inverse of the basis matrix we just need to swap the basis and component matrices here.

Member fiber_bundle::inverse (const gl2 &xgl, gl2 &xresult)

What do we want to do here? If the component matrix is already the inverse of the basis matrix we just need to swap the basis and component matrices here.

Member fiber_bundle::inverse (const gl3 &xgl, gl3 &xresult)

What do we want to do here? If the component matrix is already the inverse of the basis matrix we just need to swap the basis and component matrices here.

Member fiber_bundle::inverse (const gl3_lite &xlite, gl3_lite &xresult)

What do we want to do here? If the component matrix is already the inverse of the basis matrix we just need to swap the basis and component matrices here.

Member fiber_bundle::jcb_algebra::pull (const jcb_e13 &xjcb, const e3 &xcovector, e1 &xresult, bool xauto_access)

What do we want here?

Member fiber_bundle::jcb_algebra::pull (const jcb_e13_lite &xjcb, const e3_lite &xcovector, e1_lite &xresult)

What do we want here?

Member fiber_bundle::jcb_algebra::pull (const jcb_e23 &xjcb, const e3 &xcovector, e2 &xresult, bool xauto_access)

What do we want here?

Member fiber_bundle::jcb_algebra::pull (const jcb_e33 &xjcb, const e3 &xcovector, e3 &xresult, bool xauto_access)

What do we want here?

Member fiber_bundle::jcb_algebra::pull (const jcb_e33_lite &xjcb, const e3_lite &xcovector, e3_lite &xresult)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e13 &xjcb, const e1 &xvector, e3 &xresult, bool xauto_access)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e13_lite &xjcb, const e1_lite &xvector, e3_lite &xresult)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e23_lite &xjcb, const e2_lite &xvector, e3_lite &xresult)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e23 &xjcb, const e2 &xvector, e3 &xresult, bool xauto_access)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e33_lite &xjcb, const e3_lite &xvector, e3_lite &xresult)

What do we want here?

Member fiber_bundle::jcb_algebra::push (const jcb_e33 &xjcb, const e3 &xvector, e3 &xresult, bool xauto_access)

What do we want here?

Class fiber_bundle::jcb_e13

Is there really anything Euclidean about this class?

Class fiber_bundle::jcb_e23

Is there really anything Euclidean about this class?

Class fiber_bundle::jcb_e33

is there really anything Euclidean about this class?

Member fiber_bundle::jcb_lite::table_dofs () const

: where do these strings get deleted?

Member fiber_bundle::linear_1d::volume (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf)

For xdf == 1 we can just take the absolute value of x1-x0 (no need to take the sqrt of the product).

Member fiber_bundle::linear_2d::coord_at_value (const dof_type xdofs[], size_type xdofs_ub, const dof_type xglobal_coords[], size_type xglobal_coord_ub, dof_type xlocal_coords[], size_type xlocal_coords_ub) const

Made unexecutable because it is true only in exact arithmetic.

Member fiber_bundle::linear_2d::jacobian (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf, const dof_type xlocal_coords[], size_type xlocal_coords_ub)

This method is broken.

Member fiber_bundle::linear_2d::volume (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf)

For xdf == 2 the area is 0.5*(x1-x0)*(y2-y0)-(x2-x0)*(y1-y0)); so for efficiency we use tis equation.

Member fiber_bundle::local_base_space_member::invariant () const

what are the invariants for this class

Member fiber_bundle::point_block_1d::point_block_1d (poset *xhost, const size_type &xi_size, bool xauto_access)

xi_size argument must be precisely the right type, / in particular not type int, otherwise the wrong version / of the overloaded ctor will be chosen by the compiler. / This near ambiguity will dissappear when relative indexing / is implemented. /

Member fiber_bundle::product_section_space_schema_member::invariant () const

what are the invariants for this class

Member fiber_bundle::product_section_space_schema_member::size (pod_index_type xdisc_id, pod_index_type xfiber_dof_id, bool xis_table_dof) const

This signature is redundant for xis_table_dof true, but without the xis_table_dof argument this signature creates an overload ambiguity with size(pod_index_type, bool). Similar problem occurs with alignment, type, and offset.

Member fiber_bundle::product_section_space_schema_poset::new_state (const schema_poset_member &xschema, array_poset_dof_map &xdof_map)

the following is unexecutable because dof maps don't have a schema until attached to a host; requires covariant schema feature to implement.

Member fiber_bundle::quadratic_1d::coord_at_value (const dof_type xdofs[], size_type xdofs_ub, const dof_type xglobal_coords[], size_type xglobal_coord_ub, dof_type xlocal_coords[], size_type xlocal_coords_ub) const

Made unexecutable because it is true only in exact arithmetic.

Member fiber_bundle::quadratic_1d::volume (const dof_type xcoord_dofs[], size_type xcoord_dofs_ub, size_type xdf)

Note that this is "isoparametric" which means that for xdf == 2 or xdf == 3 the 1d segment may not be straight. For now we assume that it is.

For xdf == 1 we can just take the absolute value of x1-x0 (no need to take the sqrt of the product).

Member fiber_bundle::quadratic_2d::coord_at_value (const dof_type xdofs[], size_type xdofs_ub, const dof_type xglobal_coords[], size_type xglobal_coord_ub, dof_type xlocal_coords[], size_type xlocal_coords_ub) const

Made unexecutable because it is true only in exact arithmetic.

Member fiber_bundle::quadratic_3d::coord_at_value (const dof_type xdofs[], size_type xdofs_ub, const dof_type xglobal_coords[], size_type xglobal_coord_ub, dof_type xlocal_coords[], size_type xlocal_coords_ub) const

Made unexecutable because it is true only in exact arithmetic.

Member fiber_bundle::sec_at0_algebra::acos (const sec_at0 &x0, sec_at0 &xresult, bool xauto_access)

The above 2 preconditions result in memory leaks. How do we want to deal with them?

Member fiber_bundle::sec_at0_algebra::asin (const sec_at0 &x0, sec_at0 &xresult, bool xauto_access)

The above 2 preconditions result in memory leaks. How do we want to deal with them?

Member fiber_bundle::sec_jcb::comp2 (int row, int col) const

Where do these functions go?

Member fiber_bundle::sec_rep_descriptor_poset::terminate_access ()

we should either prevent termination if other clients exist or have some mechanism for notifying them of termination. Currently we can't do either one.

Member fiber_bundle::sec_rep_space::new_state (const poset_path &xpath, const schema_poset_member &xschema, array_poset_dof_map &xdof_map)

the following is unexecutable because dof maps don't have a schema until attached to a host; requires covariant schema feature to implement.

Member fiber_bundle::sec_tp_space::is_covariant (pod_index_type xmbr_id, int xi, bool xauto_access) const

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fiber_bundle::sec_vd_algebra::binary_op (const S0 &x0, const S1 &x1, SR &xresult, F xfunctor, bool xauto_access)

How do we ensure that this dof type is the same as that of the fibers?

Member fiber_bundle::sec_vd_algebra::binary_op (const S0 &x0, const vd_value_type &x1, SR &xresult, F xfunctor, bool xauto_access)

How do we ensure that this dof type is the same as that of the fibers?

Member fiber_bundle::sec_vd_space::is_covector (pod_index_type xmbr_id, bool xauto_access) const

Want this implementation to work for vd and its various tensor descendants, except for at0. For vd itself, the implementation is straight forward, there's one covariance subposet and a vd is_covector if it is a member of the covariance subposet.

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fiber_bundle::sec_vd_space::is_vector (pod_index_type xmbr_id, bool xauto_access) const

Want this implementation to work for vd and its various tensor descendants, except for at0. For vd itself, the implementation is straight forward, there's one covariance subposet and a vd is_covector if it is a member of the covariance subposet.

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fiber_bundle::section_component_iterator::update_item ()

resets host, which is unnecessary except when called from reset_item. Would be more efficient to just reset indices; avoids call to _item.init_handle_data_members

Member fiber_bundle::section_dof_iterator::force_is_done ()

the above requirement is probably a symptom of bad design. Either is_done should not be virtual or this class should not inherit poset_dof_iterator, because poset_dof_iterator::force_is_done has no way to actually ensure the virtual is_done postcondition.

Member fiber_bundle::section_space_schema_member::invariant () const

what are the invariants for this class

Member fiber_bundle::section_space_schema_member::size (pod_index_type xdisc_id, pod_index_type xfiber_dof_id, bool xis_table_dof) const

This signature is redundant for xis_table_dof true, but without the xis_table_dof argument this signature creates an overload ambiguity with size(pod_index_type, bool). Similar problem occurs with alignment, type, and offset.

Member fiber_bundle::section_space_schema_member::size (pod_index_type xdisc_id, pod_index_type xfiber_dof_id, bool xis_table_dof) const =0

This signature is redundant for xis_table_dof true, but without the xis_table_dof argument this signature creates an overload ambiguity with size(pod_index_type, bool). Similar problem occurs with alignment, type, and offset.

Member fiber_bundle::section_space_schema_poset::terminate_access ()

we should either prevent termination if other clients exist or have some mechanism for notifying them of termination. Currently we can't do either one.

Class fiber_bundle::st2_e3

Is this class named correctly, is the underlying vector space really E3 or just R3?

Member fiber_bundle::structured_block::refine_point (const chart_point &xpt) const

In principle, this class inherits local_base_space_member. However, this would require multiple inheritance, which we have decided not to use. So the features of local_base_space_member are simply duplicated in this class.

Member fiber_bundle::structured_block::unrefine_point_pa (const chart_point &xpt, chart_point &result) const =0

the following precondition attempts to require that xpt is a direct refinement of this. But covers() fails to correctly capture this requirement because there may be jrms between this and its direct refinement.

Member fiber_bundle::symmetric_matrix_3x3< T >::is_positive_definite () const

This is NOT the most efficient way to do this. But it gets the job done.

Member fiber_bundle::t2_e2::t2_e2 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::t2_e3::t2_e3 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::t3_e3::t3_e3 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::t4_e2::t4_e2 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::t4_e3::t4_e3 (poset_state_handle &xhost, const row_dofs_type &xrdt, bool xauto_access=true)

Why do we have "poset* xhost" instead of "poset_state_handle* xhost" above?

Member fiber_bundle::tp_lite::table_dofs () const

Where do these c_strings get deleted?

Member fiber_bundle::tp_lite::vector_space_type

we may need to move this up to vd

Member fiber_bundle::tp_space::is_covariant (pod_index_type xmbr_id, int xi, bool xauto_access) const

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fiber_bundle::unstructured_block_builder::build_block_pa (const base_space_member *xtemplate, const int *xglue, size_type xglue_ub, unstructured_block *result, bool xcompute_upper_cover, bool xauto_access)

Order relation for block member. The there 2 major steps in building a block:

Create all the cells implied by the template and the glue, making sure to identify and use equivalent existing members.
Properly link the cells and the block member to existing members making sure to satsify the ordering relation implied by the expansion of the block. This algorithm should operate in two modes:

Computed; the proper linkage is automatically computed by joining the cells.
Assumed ("trust me"); the upper cover of the block member is assumed to already be correct and the lower cover is assumed to be the collection of cells.

Member fiber_bundle::vd_algebra::factorial (unsigned int xi)

Where should we put these functions?

Member fiber_bundle::vd_algebra::transform_basis_by (e3_lite &xv, const gl3_lite &xtransform, bool is_contravariant=true)

its annoying that we have to implement the co- and contra-variant cases entirely separately. A more general implementation based on the notion of inner products of i-th row with j-th column (or row) would be better.

Member fiber_bundle::vd_algebra::transform_basis_by (st2_e3_lite &xv, const gl3_lite &xtransform, bool is_contravariant)

What do we want to do here?

Member fiber_bundle::vd_lite::table_dofs () const

Where does this string get deleteed?

Member fiber_bundle::vd_space::is_covector (pod_index_type xmbr_id, bool xauto_access) const

Want this implementation to work for vd and its various tensor descendants, except for at0. For vd itself, the implementation is straight forward, there's one covariance subposet and a vd is_covector if it is a member of the covariance subposet.

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fiber_bundle::vd_space::is_vector (pod_index_type xmbr_id, bool xauto_access) const

Want this implementation to work for vd and its various tensor descendants, except for at0. For vd itself, the implementation is straight forward, there's one covariance subposet and a vd is_covector if it is a member of the covariance subposet.

Access by name lookup is not terribly efficient, but it will have to do until we get id spaces for subposets working or devise some other mechanism.

Member fields::average_push_action::average_push_action (int xdst_df)

assumes binary schema.

Member fields::avg_section_pusher::avg_section_pusher (const avg_section_pusher &xother)

does anything need to happen or does section_pusher handle it all?

Member fields::body_pusher::push_pa (const base_space_member &xinput, base_space_member &result, bool xcompute_upper_bound, bool xauto_access)

should join produce new jem or not? If not, must relax name postcondition to has_name.

Member fields::edge_centered_polygon_refiner::make_new_vertices (field_refinement_buffer &xbuffer)

assume the lower cover of the zone contains only vertices.

Member fields::edge_centered_polygon_refiner::modify_subposets (field_refinement_buffer &xbuffer)

There's subtle question here: what defines the membership of the elements subposet? For instance, is it all the triangle shaped cells, or just the finest ones that are also jims? We're following the latter definition. The elements subposet is frequently used as an evaluation subposet and we don't want non-jims showing up as evaluators.

is this producing some sort of efficiency problem by scattering dofs allocated on this sequence id?

Member fields::field_refinement_buffer::evaluate_at_center ()

requires same evaluation subposet.

Member fields::field_refinement_buffer::evaluate_source_at_disc (size_type xi)

requires coord dofs are coord values.

requires same evaluation subposet.

Member fields::field_refinement_buffer::field_refinement_buffer (const field_vd &xsource, field_vd &xtarget, const block< scoped_index > &xcoord_disc_ids, const block< scoped_index > &xprop_disc_ids, int xdepth_ub)

Assuming that the discretization id space is a scattered_insertion_index_space. This is true because refinement is currently only implemented on unstructured blocks (or potentially zone node blocks). Once zone node blocks support binary id spaces, this assumption is not true. See bug 0000381.

Member fields::field_refinement_buffer::field_refinement_buffer (field_vd &xtarget, const block< scoped_index > &xcoord_disc_ids, const block< scoped_index > &xprop_disc_ids, int xdepth_ub)

Assuming that the discretization id map is a scattered_insertion_index_map. This is true because refinement is currently only implemented on unstructured blocks (or potentially zone node blocks). Once zone node blocks support binary id spaces, this assumption is not true. See bug 0000381.

Member fields::field_vd::access_control_disabled ()

this class needs the public interface of read_write_monitor_handle, but it can't inherit it, because, since it has two state objects, not one, it can't support the private state_obj() method. Nor are the member function implementations in read_write_monitor_handle which use state_obj() valid for this class. What we need is an abstract class that introduces just the public interface.

Member fields::field_vd::field_vd (namespace_poset &xns, const poset_path &xcoordinates_path, const poset_path &xproperty_path, bool xauto_access)

how to we create the specific section type for the property?

Member fields::field_vd::put_property_dofs (const sec_vd &xcoordinates, sec_vd &xproperty, property_dof_function_type xproperty_dofs_fcn, bool xauto_access)

Have to transfer context values array to block. because context has array and dof function wants block.

Member fields::field_vd::put_property_dofs (const sec_vd &xcoordinates, sec_vd &xproperty, put_property_dofs_action &xproperty_dofs_action, bool xauto_access)

Have to transfer context values array to block. because context has array and dof function wants block.

Member fields::print_property_dofs_action::print_property_dofs_action (sec_vd &xproperty, property_dof_function_type xfcn, bool xzero_specified=false)

assuming binary schema, one dof per component.

Member fields::property_disc_iterator_4_2::invariant () const

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::property_disc_iterator_4_2::property_disc_iterator_4_2 (const field_vd &xfield)

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::property_disc_iterator_4_2::property_disc_iterator_4_2 (const section_space_schema_member &xcoordinate_schema, const section_space_schema_member &xproperty_schema)

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::property_disc_iterator_4_3::invariant () const

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::property_disc_iterator_4_3::property_disc_iterator_4_3 (const field_vd &xfield)

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::property_disc_iterator_4_3::property_disc_iterator_4_3 (const section_space_schema_member &xcoordinate_schema, const section_space_schema_member &xproperty_schema)

We can't support prop base < coord base in this implementation because we traverse from the prop down and we won't find the coord eval.

Member fields::put_property_dofs_action::put_property_dofs_action (sec_vd &xproperty, bool xauto_access)

assuming binary schema, one dof per component.

Member fields::section_pusher::section_pusher (const sec_rep_space &xdomain, const sec_rep_space &xrange, const sec_ed &xdomain_coord, const sec_ed &xrange_coord, bool xauto_access)

Either _domain and _range should be const pointers or this constructor should pass in non-const referrences.

Member fields::zone_centered_segment_refiner::modify_crg (field_refinement_buffer &xbuffer)

assume the lower cover of the zone contains only its standard 2 vertices.

Member fields::zone_centered_segment_refiner::modify_subposets (field_refinement_buffer &xbuffer)

There's subtle question here: what defines the membership of the elements subposet? For instance, is it all the triangle shaped cells, or just the finest ones that are also jims? We're following the latter definition. The elements subposet is frequently used as an evaluation subposet and we don't want non-jims showing up as evaluators.

is this producing some sort of efficiency problem by scattering dofs allocated on this sequence id?

Member fields::zone_centered_tet_refiner::modify_crg (field_refinement_buffer &xbuffer)

assume the lower cover of the zone contains only its standard 3 vertices.

Member fields::zone_centered_triangle_refiner::modify_crg (field_refinement_buffer &xbuffer)

assume the lower cover of the zone contains only its standard 3 vertices.

Member fields::zone_centered_triangle_refiner::modify_subposets (field_refinement_buffer &xbuffer)

There's subtle question here: what defines the membership of the elements subposet? For instance, is it all the triangle shaped cells, or just the finest ones that are also jims? We're following the latter definition. The elements subposet is frequently used as an evaluation subposet and we don't want non-jims showing up as evaluators.

is this producing some sort of efficiency problem by scattering dofs allocated on this sequence id?

Member geometry::array_cylindrical_point_locator::update_bins ()

block.reserve doesn't reallocate if capacity is already large enough; so storage will never shrink.

Member geometry::d_array_point_locator< DC, DB >::update_bins ()

block.reserve doesn't reallocate if capacity is already large enough; so storage will never shrink.

Member geometry::d_uniform_point_locator< DC, DB >::all_points_at_value (const sec_vd_value_type *xvalue, size_type xvalue_ub, block< chart_point_3d > &xresult)

does clipping make sense here? We've already expanded the domain slightly in update_domain(), why do we need to clip as well?

Member geometry::d_uniform_point_locator< DC, DB >::point_at_value (const sec_vd_value_type *xvalue, size_type xvalue_ub, chart_point &xresult)

does clipping make sense here? We've already expanded the domain slightly in update_domain(), why do we need to clip as well?

Member geometry::db0_point_locator< DC >::update_bins ()

block.reserve doesn't reallocate if capacity is already large enough; so storage will never shrink.

Member geometry::line_surface_intersecter::intersect (const e3_lite &xp0, const e3_lite &xp1, intersection_set_type &xresult) const

: Subsequent intersections at the same z will not be entered.

Member sheaf::abstract_poset_member::create_cover_link (abstract_poset_member *xlesser)

should we allow direct creation and linking of jrms? require(is_jim() && xlesser->is_jim());

Member sheaf::abstract_poset_member::delete_cover_link (abstract_poset_member *lesser)

should we allow direct creation and linking of jrms? require(is_jim() && xlesser->is_jim());

Member sheaf::abstract_poset_member::hub_id_space () const

Do these functions need to virtual?

Member sheaf::abstract_poset_member::invariant () const

what are the other invariants for this class

Member sheaf::abstract_poset_member::new_jrm_state (bool xauto_access=true)

should we allow direct creation and linking of jrms?

Member sheaf::abstract_poset_member::new_jrm_state (poset_state_handle *xhost, bool xauto_access=true)

should we allow direct creation and linking of jrms?

Member sheaf::abstract_poset_member::unrestricted_schema () const

what does the schema feature mean for a member that doesn't have a dof map?

Member sheaf::abstract_poset_member::unrestricted_schema ()

what does the schema feature mean for a member that doesn't have a dof map?

Member sheaf::array_index_space_interval::contains_unglued_hub (pod_type xlocal_id, pod_type xid) const

Using a linear search to minimize storage. For _ids_per_space, of 4 and under a linear search is as efficient as hashing. For 8 ids per space it is probably slightly slower. However, no extra storage is needed for the linear search. This function is probably not used enough by the user to justify the extra storage. If we find hashing necessary, we should use lazy instantiation to create maps from hub ids per id space.

Member sheaf::array_index_space_interval::pod (pod_type xlocal_id, pod_type xid) const

Using a linear search to minimize storage. For _ids_per_space, of 4 and under a linear search is as efficient as hashing. For 8 ids per space it is probably slightly slower. However, no extra storage is needed for the linear search. This function is probably not used enough by the user to justify the extra storage. If we find hashing necessary, we should use lazy instantiation to create maps from hub ids per id space.

Member sheaf::array_poset_dof_map::~array_poset_dof_map ()

most string dofs a re allocated using strdup, which uses malloc, not new, so must be freed rather than deleted.

Member sheaf::attributes_record_set::write_toc_bounds_attribute ()

this won't be true when we replace HDF variable length data types with libSheaf variable length records.

Member sheaf::auto_block< T, S >::assign (const_reference_type xitem)

unexecutable because it requires T to define operator==.

Member sheaf::auto_block< T, S >::assign (index_type xbegin, index_type xend, const_reference_type xitem)

unexecutable because it requires T to define operator==.

Member sheaf::auto_block< T, S >::back () const

unexecutable because it requires T to define operator==.

Member sheaf::auto_block< T, S >::force_item (index_type xindex, const_reference_type xitem)

unexecutable because it requires T to define operator==.

Member sheaf::auto_block< T, S >::push_back (const_reference_type item)

unexecutable because it requires T to define operator==.

Member sheaf::auto_block< T, S >::set_item (index_type xindex, const_reference_type xitem)

unexecutable because it requires T to define operator==.

Member sheaf::binary_index_block< T >::operator[] (int xi) const

with this operator, the expression b[i][j], / where b is a block should evaluate to the value of the item at i,j. / But what we really want is a reference to the item. / To do this we'll probably need some sort of intermediate type that / this operator can return, but then there may be efficiency issues. /

Member sheaf::data_converter::externalize (void *xext_buf, size_t xext_buf_ub, int xitem_ct)

we need to make this routine inlineable.

Member sheaf::data_converter::externalize (const void *xint_buf, size_t xint_buf_ub)

we need to make this routine inlineable.

Member sheaf::data_converter::internalize (void *xbuf, size_t xbuf_ub)

we need to make this routine inlineable.

Member sheaf::data_converter::internalize (const void *xext_buf, size_t xext_buf_ub, void *xint_buf, size_t xint_buf_ub, int xitem_ct)

we need to make this routine inlineable.

Member sheaf::data_converter::internalize (void *xbuf, size_t xbuf_ub, int xitem_ct)

we need to make this routine inlineable.

Member sheaf::data_converter::~data_converter ()

H5Pclose seems to always return failure.

Member sheaf::data_type_map::data_type_map (const data_type_map &xother)

need reference counting here.

Member sheaf::deep_size (const schema_descriptor &xsd, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member sheaf::deep_size (const poset_path &xpath, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member sheaf::deep_size (const arg_list::arg_type &xtype, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member sheaf::deep_size (const explicit_index_space_state &xn, bool xinclude_shallow=true)

The product structure should have deep_size functions to deal with the covariant types but since the current product structure only has data members that are size_t we can use size_of.

Member sheaf::deep_size (const implicit_entry_map< E, I > &xmap, bool xinclude_shallow=true)

Since the deletion will be handled by this map should the deep_size?

Member sheaf::deep_size (const primitive_value &xpv, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member sheaf::deep_size (const subposet &xsp, bool xinclude_shallow=true)

This function is incorrectly implemented.

Member sheaf::depth_first_iterator::lesser_index () const

the preconditions above ensure that the dereference of _path_head_lc in the following will succeed, as long as this routine is called from client level. If called internally from the INC_COVER_ITERATOR state, the dereference could fail. Such a call is inappropriate, but how do we express this fact as a precondition?

Member sheaf::depth_first_iterator::next (bool xtruncate)

Here and beyond is unreachable; remaining code commented out to avoid compiler warnings.

Member sheaf::depth_first_itr< T >::lesser_index () const

the preconditions above ensure that the dereference of _path_head_lc in the following will succeed, as long as this routine is called from client level. If called internally from the INC_COVER_ITERATOR state, the dereference could fail. Such a call is inappropriate, but how do we express this fact as a precondition?

Member sheaf::depth_first_itr< T >::next (bool xtruncate)

Here and beyond is unreachable; remaining code commented out to avoid compiler warnings.

Member sheaf::dof_tuple_class_names_record::~dof_tuple_class_names_record ()

can we just not define this function?

Member sheaf::dof_tuple_col_bounds_record::~dof_tuple_col_bounds_record ()

can we just not define this function?

Member sheaf::dof_tuple_domain_offsets_record::~dof_tuple_domain_offsets_record ()

can we just not define this function?

Member sheaf::dof_tuple_record_set::_next_record_pod

ambiguous use of term "record". We're using "record" in two different ways. The original meaning was that a record was the external image of a dof tuple. When we began to support variable length dof tuples, record came to mean buffer record, the unit of contiguous data transfer to and from disk. This meaning of record is more or less the same thing as an HDF chunk.

Member sheaf::dof_tuple_record_set::create_dataset ()

the following hack refers to code that has been removed, but the issue remians: what if dof_ct == 0.

Member sheaf::dof_tuple_record_set::get_internal_record (pod_index_type xext_rec_pod)

cache maintenance policy. Policy used here is that _next_record_pod repeatedly cycles through records in the cache. Since we should be accessing the records mostly sequentially, this policy is a crude approximation to least-recently-used.

Member sheaf::dof_tuple_record_set::write_selection ()

if writing to existing dataset, don't always need to extend selection.

Member sheaf::dof_tuple_schema_ids_record::~dof_tuple_schema_ids_record ()

can we just not define this function?

Member sheaf::dof_tuple_schema_versions_record::~dof_tuple_schema_versions_record ()

can we just not define this function?

Member sheaf::dof_tuple_types_record::~dof_tuple_types_record ()

can we just not define this function?

Member sheaf::forwarding_index_space_handle::new_product_structure (const abstract_product_structure &xproduct)

_host needs to const because the attach_to interface passes a const host. This is only necessary because the attach_to interface is public. The interval classes want to use this interface and we don't want to make every interval a friend. The interval calls it from get_id_space which is const.

Member sheaf::id_space_names_record::transfer_internal_buffer_to_poset ()

Reading in the map class name from the file. Should we allow this or should we assume that all maps are hash_index_maps. The only issue is that array_index_map that are not dense are inefficient.

Member sheaf::implicit_entry_map< E, I >::remove_entry (pod_type xid, bool xremove_interval)

This can be more efficient. The calls to contains_* can be replaced with access to the data structures which can be used for the removal.

This could be done more efficiently since we already found the previous and next pointers (see the implementation of remove_implicit_interval).

Member sheaf::implicit_entry_map_iterator< E, I >::next ()

This is not very efficient. Maybe this should be a mode or we should have a const iterator and a mutable iterator.

Member sheaf::interval_index_space_record::~interval_index_space_record ()

can we just not define this function?

Member sheaf::map_record::~map_record ()

can we just not define this function?

Member sheaf::member_class_names_record::~member_class_names_record ()

can we just not define this function?

Member sheaf::member_member_poset_bounds::attach_to_state (poset_state_handle *xhost)

using zn_to_bool here wastes space.

Member sheaf::member_names_record::~member_names_record ()

can we just not define this function?

Member sheaf::member_record_set::create_dataset ()

extendible dataspaces are probably not needed for all posets

Member sheaf::namespace_poset_dof_map::put_dof (pod_index_type xdof_id, const void *xdof, size_type xdof_size)

xdof should be const but the compiler does not like the reinterpret_cast to const poset_state_handle** and const char**

Member sheaf::namespace_poset_member::invariant () const

what are the invariants for this class

Member sheaf::partial_poset_member::attach_handle_data_members ()

what does the schema feature mean for a member that doesn't have a dof map?

Member sheaf::poset::new_state (const poset_path &xpath, const schema_poset_member &xschema, array_poset_dof_map &xdof_map)

the following is unexecutable because dof maps don't have a schema until attached to a host; requires covariant schema feature to implement.

automatic vs explicit version subposet membership. The crg of the coarsest_common_refinement (CCR) is what is written to disk, along with membership info for each of the version subposets. When we read the file, we want to reconstruct the CCR graph and the membership for each of the versions. The CCR graph gets reconstructed without issue, since that is what is in the file. For non-versioned posets, the subposet membership gets reconstructed correctly as well, since there are no version subposets and both CCR and whole() refer to the same subposet. But for refinable posets, when a member is created it is automatically entered into the CCR and, separately, into the current version subposet. This automatic subposet membership management conflicts with the explicit subposet membership management provided by the i/o subsystem.

current version. The above hack leaves the poset with CCR as the current version. What should the current version be, and where should we restore it?

automatic vs explicit version subposet membership. The crg of the coarsest_common_refinement (CCR) is what is written to disk, along with membership info for each of the version subposets. When we read the file, we want to reconstruct the CCR graph and the membership for each of the versions. The CCR graph gets reconstructed without issue, since that is what is in the file. For non-versioned posets, the subposet membership gets reconstructed correctly as well, since there are no version subposets and both CCR and whole() refer to the same subposet. But for refinable posets, when a member is created it is automatically entered into the CCR and, separately, into the current version subposet. This automatic subposet membership management conflicts with the explicit subposet membership management provided by the i/o subsystem.

current version. The above hack leaves the poset with CCR as the current version. What should the current version be, and where should we restore it?

Member sheaf::poset_bounds_descriptor::invariant () const

are there any clauses in this invariant?

Member sheaf::poset_bounds_descriptor::mode_to_int (specification_mode xmode)

The C++ standard says this map is unnecessary. But we've implemented anyway, just in case not all compilers follow the standard.

Member sheaf::poset_component::attach_to_state (const poset_component *xother)

need some way to enforce attachment to valid handles, in particular to enforce members to members and subposets to subposets, but the following is too strict. Won;t let schema_poset_members attach to abstract_poset_member.

Member sheaf::poset_component::attach_to_state (const poset_state_handle *xhost, pod_index_type xhub_id)

poset_component::attach_to_state() only precondition requires read_access

Member sheaf::poset_component::is_same_state (const poset_component *xother) const

how do we enforce the "same kind of component" condition? The following is too stringent, it won't allow descendants of abstract_poset_member to interoperate: result = result && is_ancestor_of(xother);

Member sheaf::poset_dft::recursive_dft (abstract_poset_member *xmbr)

Comments on possible optimization:

Member sheaf::poset_general_record::transfer_internal_buffer_to_poset ()

is this field obsolete?

Member sheaf::poset_general_record::transfer_poset_to_internal_buffer ()

this won't be true when we replace HDF variable length data types with libSheaf variable length records.

Member sheaf::poset_powerset_state::new_subposet (const block< pod_index_type > &xmembers)

Do we want to reuse the subposet index when the last member is deleted? If so, uncomment the code below (including the postcondition). This was working before because _subposet_index_ub was not updated when a member was deleted. scoped_index result = _id_spaces.new_id(subposet_index_ub());

Member sheaf::poset_powerset_state::new_subposet (const block< scoped_index > &xmembers, scoped_index &xresult)

Do we want to reuse the subposet index when the last member is deleted? If so, uncomment the code below (including the postcondition). This was working before because _subposet_index_ub was not updated when a member was deleted. scoped_index result = _id_spaces.new_id(subposet_index_ub());

Member sheaf::poset_powerset_state::new_subposet (bool xinitializ)

Do we want to reuse the subposet index when the last member is deleted? If so, uncomment the code below (including the postcondition). This was working before because _subposet_index_ub was not updated when a member was deleted. scoped_index result = _id_spaces.new_id(subposet_index_ub());

Member sheaf::poset_state_handle::attach_to_state (const abstract_poset_member *xmbr)

should haandles have type_ids?

Member sheaf::poset_state_handle::attach_to_state (const poset_state_handle *xother)

how do we require that the state of other conforms to the state required by this, especially in descendants, e.g. namespace_poset.

Member sheaf::poset_state_handle::begin_jim_edit_mode (bool xauto_access=true)

visibility of jim edit mode. begin/end_jim_edit really shouldn't be public, because they are inherited by the immutable posets primitives_poset and primitives_poset_schema. But KCC seems to be unhappy about a public virtual function in class poset overriding a private virtual function from a base class, so we've made them public here.

Member sheaf::poset_state_handle::ensure_lattice_invariant ()

Depends on bottom is index 0 and top is index 1.

this algorithm does not make top cover bottom in empty poset. The mathematical meaning is unclear, but it seems to work just fine.

Member sheaf::poset_state_handle::initialize_standard_members ()

top does not cover bottom in empty poset. The mathematical meaning is unclear, but it seems to work just fine, except that we have to make sure bottom appears in the file id map, see member_record_set::make_idorder_file_maps.

Member sheaf::poset_state_handle::is_attached () const

this implementation appears to be identical to the inherited version and hence is apparently unnecessary.

Member sheaf::poset_state_handle::is_empty () const

is this the right definition?

Member sheaf::poset_state_handle::new_state (const poset_path &xpath, const schema_poset_member &xschema, array_poset_dof_map &xdof_map)

the following is unexecutable because dof maps don't have a schema until attached to a host; requires covariant schema feature to implement.

Member sheaf::poset_state_handle::row_dof_map_conforms (const poset_dof_map *xdof_map) const

This routine tests only for covariant conformance. So an instance of section_dof_map will pass this test because section_dof_map inherits poset_dof_map. However, section_dof_map does not really functionally conform to poset_dof_map currently because some member functions are unimplemented. So passing this test doesn't really ensure the dof map will work in this poset.

Member sheaf::poset_state_handle::terminate_access ()

we should either prevent termination if other clients exist or have some mechanism for notifying them of termination. Currently we can't do either one.

Member sheaf::poset_type

This enumeration creates an unnecessary coupling between sheaves and fiber_bundles. It can and should be eliminated.

Member sheaf::primitive_traits< bool >::hdf_type ()

The return type is declared int to encapsulate hdf, but the actual type for these type ids is hid_t, which is currently (hdf1.8.0 beta) typdef'd to int. This is unlikely to change, but if it does, it could errors.

HDF doesn't support bool!

Member sheaf::ragged_array< T >::invariant () const

values() == 0 when using the default constructor.

Member sheaf::ragged_array_index_space_interval::contains_unglued_hub (pod_type xlocal_id, pod_type xid) const

Using a linear search to minimize storage. For ids per space, of 4 and under a linear search is as efficient as hashing. For 8 ids per space it is probably slightly slower. However, no extra storage is needed for the linear search. This function is probably not used enough by the user to justify the extra storage. If we find hashing necessary, we should use lazy instantiation to create maps from hub ids per id space.

Member sheaf::ragged_array_index_space_interval::pod (pod_type xlocal_id, pod_type xid) const

Using a linear search to minimize storage. For _ids_per_space, of 4 and under a linear search is as efficient as hashing. For 8 ids per space it is probably slightly slower. However, no extra storage is needed for the linear search. This function is probably not used enough by the user to justify the extra storage. If we find hashing necessary, we should use lazy instantiation to create maps from hub ids per id space.

Member sheaf::record_map< internal_index_type, external_index_type >::remove_internal_id (internal_index_type xinternal_id)

the following condition, and the postcondition !ub_is_max below, are stronger than really necessary, since xinternal_id may not have actually been removed. But it is not clear how to define the precise postcondition and this one properly informs the client that removing entries compromises ub_is_max.

Member sheaf::record_set::NOT_AN_HDF_ID

does HDF have a defined value for this? /

Member sheaf::record_set::write_attribute (const void *xatt_values, size_type xatt_ct, const data_converter *xatt_conv, const std::string &xatt_name)

does deleting and rewriting the attribute everytime we write to the dataset imply a resource leak in the file?

Member sheaf::schema_poset_member::conforms_to (const schema_poset_member &xother, bool xis_table_dofs) const

the definition of conformance implemented here is stricter than theoretically necessary. Theoretically, conformance should just require that the set of dofs defined by this schema contains the set of dofs defined by xother. But all the schema traversal algorithms and the dof access mechanisms depend on the dofs being ordered, hence the definition used here.

Member sheaf::schema_poset_member::invariant () const

what are the invariants for this class

Member sheaf::schema_poset_member::row_dof_subposet_index () const

this precondition is only needed for the postcondition.

Member sheaf::schema_poset_member::table_dof_subposet_index () const

this precondition is only needed for the postcondition.

Member sheaf::scoped_index::is_equivalent_to (const scoped_index &xother) const

is_equivalent_to will return true if neither this nor xother are in_scope. Is that right? Is there a single non-member that they both refer to?

Member sheaf::sheaf_constants::primitive_type

does the above really belong here?

Member sheaf::storage_agent::commit_transaction (poset_state_handle &xposet)

Should really be read-write accessible so that the new id space functions can require write access. However, writing only requires read access in general.

Member sheaf::storage_agent::initialize_poset_id_spaces_for_write (poset_state_handle &xposet)

Should really be read-write accessible so that the new id space functions can require write access. However, writing only requires read access in general.

Member sheaf::storage_agent::read_row_decomposition (poset_state_handle &xposet, const scoped_index &xdecomp_id)

may want to introduce a state machine to coordinate multiple partial read/write transactions.

Member sheaf::storage_agent::write_prerequisites (const poset_scaffold &xscaffold)

if we retain read access in the main write, do we need to retain read access to all the prerequisites?

we can't actually ensure the following if we've released read access.

Member sheaf::subposet::extremals_pa (bool xmaximals, subposet *result)

why can't we just created it strict?

Member sheaf::total_poset_member::invariant () const

what are the invariants for this class

Member sheaf::WHOLE_INDEX

1 is in fact the index of the coarsest common refinement whole. It is whole().index() only for posets which are not descendants of refinable_poset. See poset_state_handle::initialize_standard_subposets and refinable_poset::initialize_standard_subposets.