dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 26/08/11 07:27, Anders Logg wrote:
> On Fri, Aug 26, 2011 at 07:11:11AM -0400, Garth N. Wells wrote:
>>
>>
>> On 26/08/11 02:39, Anders Logg wrote:
>>> On Thu, Aug 25, 2011 at 05:57:51PM -0400, Garth N. Wells wrote:
>>>>
>>>>
>>>> On 25/08/11 16:53, Anders Logg wrote:
>>>>> On Thu, Aug 25, 2011 at 09:59:44AM -0400, Garth N. Wells wrote:
>>>>>
>>>>>>>>> How about using DOM everywherme and reserve the use of SAX for an
>>>>>>>>> XML->HDF5 converter?
>>>>>>>>>
>>>>>>>>
>>>>>>>> That could be OK, but if we have the to implement a SAX parser it's
>>>>>>>> probably easiest to have it in DOLFIN anyway. I don't see the advantage
>>>>>>>> over having the SAX parser with the io code.
>>>>>>>
>>>>>>> I agree we should keep it in DOLFIN, but if the only thing it needs to
>>>>>>> do is extract data and spit out HDF5, I imagine it can be simpler than
>>>>>>> the current parser since it doesn't need to be parallel. (?)
>>>>>>>
>>>>>>
>>>>>> To make things clearer, I've just renamed the LocalMeshData parsers to
>>>>>>
>>>>>>   XMLLocalMeshDOM (was XMLLocalMeshData)
>>>>>>
>>>>>> and
>>>>>>
>>>>>>   XMLLocalMeshSAX (was XMLLocalMeshDataDistributed)
>>>>>
>>>>> That's good.
>>>>>
>>>>>> When XMLLocalMeshSAX is complete, it may be desirable to remove
>>>>>> XMLLocalMeshDOM.
>>>>>
>>>>> Either way is fine for me, as long as we decide which one to use. I
>>>>> initially wanted to use SAX (as before) but the DOM looks easier and
>>>>> may be enough if we plan to use HDF5 for large-scale problems anyway.
>>>>> Or is it the case that DOM is a limitation even for medium sized
>>>>> problems?
>>>>>
>>>>
>>>> It works for 'medium' (very arbitrary) size problems.
>>>>
>>>>>> I don't know what you mean by parallel - the XMLLocalMeshSAX works in
>>>>>> the same way as the old parser (each process reading a chunk). I don't
>>>>>> see how it can be made simpler by reading a XML file and then converting
>>>>>> to HDF5. The steps that are there now will all still be required to read
>>>>>> the XML mesh before writing a HDF file.
>>>>>
>>>>> I don't know HDF, but I imagine one could write one single file and
>>>>> HDF will handle parallel parsing of that file later. Then the
>>>>> conversion script we write does not need to do anything parallel, just
>>>>> read line by line and convert from one format to another.
>>>>>
>>>>
>>>> It may not be possible to do it line-by-line (I don't know, but I
>>>> wouldn't want to bank on it). Even if line-by-line is technically
>>>> possible, it could turn out to be terribly slow. We should support that
>>>> a mesh can be read into memory (distributed), and written to HDF5.
>>>>
>>>> Since we'll have support for writing HDF5 meshes, if we can read a large
>>>> XML mesh then we can re-use the HDF5 output code to make the conversion.
>>>>
>>>> I've removed the DOM-based LocalMeshData parser - there is no point to
>>>> it since we can just read the mesh on one process using XMLMesh and use
>>>> it to construct a dolfin::XMLLocalMeshData object.
>>>
>>> ok, looks good.
>>>
>>> How should we store boundary indicators? I'm not sure whether it needs
>>> to be stored as part of ParallelData. Is it really "parallel data"?
>>> ParallelData will for sure need to be used to compute it (convert
>>> somehow from the input) but it seems it can then be stored
>>> locally.
>>
>> OK. It's not really parallel data (but perhaps ParallelData should be
>> renamed).
>>
>>> Each facet just needs to know its indicator value.
>>>
>>> The input is a list of triples:
>>>
>>>   (indicator, facet_cell, facet_number)
>>>
>>> This indicates that local facet number `facet_number` of the cell
>>> `facet_cell` should have the indicator value (sub domain number)
>>> `indicator`.
>>>
>>
>> Let's make it generic:
>>
>>   (parent_cell_index, entity_dim, local_entity_index, indicator/value)
> 
> Yes, that looks good. What about the XML format? It becomes unwieldy
> to store it as 4 different MeshFunctions. Here's an initial sketch:
> 
> <mesh>
>   # cells and vertices here as before
>   <data>
>     # user data here as before
>   </data>
>   <indicators dim="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>   </indicators>
>   <indicators dim="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>     <indicator cell="..." local_entity_index="..." value="...">
>   </indicators>
>   ...
> </mesh>
> 

That looks OK, except for the name 'indicator(s)'.

Essentially what it is is a MeshFunction that is defined only on a
subset of entities of a given dimension. I think we should template it
on the C++ side so that any data can be attached. We should then have

   <indicators dim="..." type="...">

(but with something other than 'indicators'). Internally, there may be
no need to construct a MeshFunction.


>> It could go into MeshData (possibly with what's in ParallelData), and
>> the current MeshData could be renamed to something like 'UserMeshData'.
> 
> I think it's better to keep the name MeshData for user-defined data
> (and internal DOLFIN data stored there in waiting for a proper place
> to store it). mesh.data() is used in many places in user code.
> 
> It would be better to each time we decide to amend the Mesh class with
> new data to add a proper class to hold it, like ParallelData (possibly
> renamed). How about a new class called "MeshIndicators" to hold mesh
> indicators. It would need to handle initialization from various
> sources of input data, in particular MeshFunctions, which is then
> converted to some proper internal representation. The MeshIndicator
> class should be "parallel aware" and not need any special extras in
> ParallelData.
>

All fine if we can find a more appropriate name than 'Indicator'.

Garth

> --
> Anders