[MOAB-dev] measure.cpp

[Paul Wilson]

Elliott,

Given the limited needs of our current application, you could implement 
a specific version of these methods in your own project based on the 
same standard algorithms used here.

Paul

On 05/19/2014 03:33 PM, Elliott Biondo wrote:
> Thank you for the responses.
>
>     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.
>
>
> My use case is very simple. I have meshes that are made up of either 
> Carteisan hexes or tets. I want an easy way to get the volumes of each 
> mesh volume element (by supplying a volume element handle, iterator of 
> handles, etc.). For now, including the build directory and linking 
> against measure.o works fine, but I will keep an eye out for the 
> additions to ElemUtil.
>
> Thanks,
>
> Elliott Biondo
>
>
> On Mon, May 19, 2014 at 11:19 AM, Vijay S. Mahadevan 
> <vijay.m at gmail.com <mailto:vijay.m at gmail.com>> wrote:
>
>     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 <mailto: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
>     <mailto:moab-dev-bounces at mcs.anl.gov>
>     [moab-dev-bounces at mcs.anl.gov
>     <mailto:moab-dev-bounces at mcs.anl.gov>] on behalf
>     > of Elliott Biondo [Biondo at wisc.edu <mailto:Biondo at wisc.edu>]
>     > Sent: Friday, May 16, 2014 1:25 PM
>     > To: moab-dev at mcs.anl.gov <mailto: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
>
>
>
>
> -- 
> 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 
> <https://www.google.com/calendar/embed?src=elliott.biondo%40gmail.com&ctz=America/Chicago>

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140519/ac4886a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140519/ac4886a1/attachment.bin>