[MOAB-dev] measure.cpp

[Vijay S. Mahadevan]

Sorry about the late reply.

> This kind of function belongs to an "element utility" tool/class, which
> should serve multiple types of elements;

As Iulian mentioned, we are currently in the process of doing a
refactor of the ElemUtil and the spatial coupler classes to provide
more functionality to both perform discretization and common integral
operations over different entity types. The volume computation routine
that you found from measure.cpp is specific for structured grids and
so if you are unsure of the underlying mesh, I wouldn't recommend
directly using those functions.

> Vijay, do you know the status of refactoring elem util class?

I've been on vacation for a good part of April and May and hence the
completion of this work has slowed down. I hope to have this branch/PR
ready for review and then a merge by the second week of June. Let me
know if you have any specific use case that you'd like to see near
term to aid in computing element volumes, normals on a face etc.

Vijay

On Sat, May 17, 2014 at 12:28 AM, Grindeanu, Iulian R.
<iulian at mcs.anl.gov> wrote:
> Hi,
> This kind of function belongs to an "element utility" tool/class, which
> should serve multiple types of elements;
> Probably, better would be to use some gauss integration method. There is
> some work now in mbcoupler to expose more element types and more integration
> / FE / FV types.
>
> Right now, in MOAB, this method is used just for mbsize; it is not
> "installed", so you cannot "include" it. Unless you add your build folder in
> the include . Or how do you (plan to) use it?
>
> There are other issues with this method. It uses a local class CartVect,
> which is a conflict with the namespaced moab::CartVect.
>
>  as it stands, volume is computed here using linear decomposition in
> tetrahedrons, which might not be correct. It is fine for planar faced hexas.
> It could be a too big of approximation for slightly distorted hexas; also,
> depending on how you decompose a hexa in tetras (more than one way is
> possible), you get different results.
>
> Vijay, do you know the status of refactoring elem util class?
>
> Thanks,
> Iulian
>
> ________________________________
> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf
> of Elliott Biondo [Biondo at wisc.edu]
> Sent: Friday, May 16, 2014 1:25 PM
> To: moab-dev at mcs.anl.gov
> Subject: [MOAB-dev] measure.cpp
>
> I am currently using the function "measure" in measure.cpp to find the
> volumes of mesh volume elements. Currently I have to link against measure.o,
> which is compiled into the MOAB build directory, but as best as I can tell,
> it is not exposed through the MOAB library. Are there any plans to include
> this capability within the core library of MOAB, so that this function could
> be used in a more formal way?
>
> Thanks,
>
> Elliott Biondo
>
> --
> Elliott D. Biondo
> Nuclear Regulatory Commission Fellow
> Computational Nuclear Engineering Research Group (CNERG)
> Department of Nuclear Engineering and Engineering Physics
> University of Wisconsin - Madison
>
> 434 Engineering Research Building
> 1500 Engineering Drive
> Madison, WI 53706
>
> Calendar