ahernsean
commented
12 years ago So this brings up two questions in my mind. The first is whether the GetField methods needs to require an optional parameter to define the set that one is asking about. For instance, you could GetField on the cells to get the “pressure" field that is defined there. And the same GetField of “pressure” on the faces for the same thing. It’s a question of the association of GetField. Just associating it with eavlDataSet:: isn’t necessarily local enough.
But sometimes it is. As you mention, high-order fields might actually be an amalgam of fields defined over related subsets of the data. Just as we are working on collection objects like AMR grids and trees, would it be appropriate to create a set of collection objects that allow us to consider multi-field fields appropriately?
-Sean
Sean Ahern Oak Ridge National Laboratory 865-408-8463
On Sep 12, 2012, at 2:03 PM, Jeremy Meredith wrote:
Currently, the way it works is that you need to have two fields: one each with its own association. Even so, the API isn't very conducive to this. For example, eavlDataSet::GetField will only return the first instance of that field. We could change it (and related methods) to return
Of course, it makes obvious sense for two element sets to contain the same field (e.g. pressure defined on both the cells and the faces). It's less obvious why a field should be defined e.g. on both the nodes and on a cell set (though note high order comments below). So it might make more sense for a field to contain multiple arrays.
Any proper solution, though, should accommodate high order fields. For example, a quadratic field might be defined on both the nodes and the cells. Any maybe edges and faces, too. This is not an implication that a field-containing-multiple-arrays would not work, by the way -- in fact, interpolation order is part of the field, so it actually might reinforce the notion that such as solution makes sense. it just means we should not assume this only occurs for cell sets.
(One other thought: if part of a high order field is an array on the cells, should we be able to reference the field on only the cells and get a piecewise-constant field? One way of doing that is to have array contents themselves be part of the eavlDataSet, and have eavlField reference those arrays, in which case we could have a 0th order field and a 2nd order field both reference the same cell-centered array. That gets a bit messy (how do the arrays get named). So maybe it's better to instead just make it easy to pull the nodal or zonal arrays out of a high order field.)
— Reply to this email directly or view it on GitHubhttps://github.com/jsmeredith/EAVL/issues/1.
Currently, the way it works is that you need to have two fields: one each with its own association. Even so, the API isn't very conducive to this. For example,
eavlDataSet::GetFieldwill only return the first instance of that field. We could change it (and related methods) to returnOf course, it makes obvious sense for two element sets to contain the same field (e.g. pressure defined on both the cells and the faces). It's less obvious why a field should be defined e.g. on both the nodes and on a cell set (though note high order comments below). So it might make more sense for a field to contain multiple arrays.
Any proper solution, though, should accommodate high order fields. For example, a quadratic field might be defined on both the nodes and the cells. Any maybe edges and faces, too. This is not an implication that a field-containing-multiple-arrays would not work, by the way -- in fact, interpolation order is part of the field, so it actually might reinforce the notion that such as solution makes sense. it just means we should not assume this only occurs for cell sets.
(One other thought: if part of a high order field is an array on the cells, should we be able to reference the field on only the cells and get a piecewise-constant field? One way of doing that is to have array contents themselves be part of the eavlDataSet, and have eavlField reference those arrays, in which case we could have a 0th order field and a 2nd order field both reference the same cell-centered array. That gets a bit messy (how do the arrays get named). So maybe it's better to instead just make it easy to pull the nodal or zonal arrays out of a high order field.)