[MeshLib] Replacement of element classes with new implementation using TemplateElement #572

norihiro-w · 2015-01-26T11:17:54Z

This PR is based on discussion in #506 and introduces new implementations of mesh element classes by combining TemplateElement class and element-specific topological/geometrical rules.

Note: It includes two commits in #571

wenqing · 2015-01-26T12:07:57Z

MeshLib/Elements/CellRule.cpp

+		const MathLib::Vector3 cx (c, x);
+		const double s = MathLib::scalarProduct(face->getSurfaceNormal(), cx);
+		delete face;
+		if (s >= 0)


Real number comparison.

@TomFischer @rinkk how do you think?

I can not see a problem here. @wenqing What are your concerns?

we just check if two vectors are pointing in roughly the same direction. in practice, s should be nowhere near 0, if it is the element is degenerated. the test is still correct here because we are testing just for node order so technically s=0 is a valid value, even if other tests will fail because of that. (I am not 100% sure without looking up the theory again, but s=0 almost certainly means this will be a zero volume element)

wenqing · 2015-01-26T12:57:45Z

I think the current implementation has a flexibility in handling different element orders.

TomFischer · 2015-01-27T05:50:05Z

MeshLib/Elements/CellRule.cpp

+	for (unsigned j=0; j<nFaces; ++j)
+	{
+		MeshLib::Face const*const face (dynamic_cast<const MeshLib::Face*>(e->getFace(j)));
+		const MeshLib::Node x (*(face->getNode(1)));


I am curious: Is there a special reason to take node 1 of the face?

i have no idea. please ask @rinkk

This is the documentation I wrote:

* Checks if the node order of an element is correct by testing surface normals. * For 3D elements true is returned if the normals of all faces points away from the centre of * the element. * Note: This method might give wrong results if something else is wrong with the element * (non-planar faces, non-convex geometry, possibly zero volume) which causes the calculated * center of gravity to lie outside of the actual element

I think I chose node 1 because that way all nodes are used for the test at some point, while for node 0 at least one node in every element type would be used for checking twice and one wouldn't be checked at all. (based on the definition of the _face_nodes variable)

@rinkk shall I add your comment (about checking node 1) into the source so that we can avoid repating of the same question in the future?

good idea, thank you :) ✅

rinkk · 2015-01-27T11:56:19Z

For what it's worth: everything works fine under windows and with gui.
If I see this correctly, debugging will be more difficult using this implementation. (I don't like this fact but I suppose that it is not a priority.)

A general comment:
You should probably also adjust the schematics for the higher order elements, e.g. for Quad9: ✅

 *              
 *        3-----6-----2
 *        |           |
 *        |           |
 *        7     9     5
 *        |           |
 *        |           |
 *        0-----4-----1
 *

rinkk · 2015-01-27T11:58:50Z

Another question:
I see that your higher order implementation-rules are currently very small.
Can you somehow use methods from another rule (e.g. the getVolume() method) or do you simply need none of that for higher order methods?

norihiro-w · 2015-01-27T12:33:55Z

@rinkk

you are right and agree with you. debugging is more difficult. I also don't like it. Any alternative idea for easier debugging is welcome
Thanks, I'll modify the schematics for the higher order elements
With this implementation, it is possible to override getVolume() for non-linear shape elements (e.g. quad with curved edgs). I'm not doing this at the moment, because so far we are using only linear shape. Someone like TN may want to use non-linear shape for representing coverns.

rinkk · 2015-01-27T13:05:19Z

thanks for the info

norihiro-w · 2015-01-27T22:44:00Z

MeshLib/Elements/CellRule.h

+	/**
+	 * Checks if the node order of an element is correct by testing surface normals.
+	 */
+	static bool testElementNodeOrder(const Element* e);


the same function exists in Cell class ✅

norihiro-w · 2015-01-28T14:03:48Z

rebased, changed according to the comments

norihiro-w · 2015-01-28T17:11:06Z

MeshLib/Elements/QuadRule8.h

+#define QUADRULE8_H_
+
+#include "MeshLib/MeshEnums.h"
+#include "Element.h"


norihiro-w · 2015-01-30T12:09:22Z

maybe it is better to define rule functions in header files so that it helps optimization?

endJunction · 2015-02-02T11:50:51Z

MeshLib/Elements/Face.h

-
-	/// 2D elements have no faces.
-	unsigned getNFaces() const { return 0; }
+	virtual double getArea() const { return _content; }


I think getArea is nowhere used, and there is the new getContent method in the base class.
Same for the Cell::getVolume.

@rinkk is it true that getArea is nowhere used?
@endJunction getContent() is not new.

yes, getArea is not used ... it is one of the methods we included when we first implemented the MeshLib but in reality we always end up using getContent() instead ...

…tions

…ays same

[MeL] Remove unused include.

norihiro-w · 2015-02-09T16:21:10Z

Follwoing Dima's suggestion, removed T_BASE parameter from TemplateElement class

endJunction · 2015-02-09T16:52:33Z

Good work!
Someone please look one more time for typos etc. The class hierarchy and overall structure looks good. (And we have more functionality with less code in total!)

⏩

bilke · 2015-02-10T13:36:05Z

👍

[MeL] Replacement of element classes with TemplateElement<Rule>

ogsbot · 2020-06-19T12:13:23Z

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

norihiro-w added the please review label Jan 26, 2015

norihiro-w mentioned this pull request Jan 26, 2015

New implementation of mesh element classes #570

Closed

wenqing reviewed Jan 26, 2015
View reviewed changes

TomFischer reviewed Jan 27, 2015
View reviewed changes

norihiro-w reviewed Jan 27, 2015
View reviewed changes

norihiro-w force-pushed the new-imp-ele branch from 0f784e3 to a9635a7 Compare January 28, 2015 13:16

norihiro-w reviewed Jan 28, 2015
View reviewed changes

MeshLib/Elements/QuadRule8.h

#define QUADRULE8_H_

#include "MeshLib/MeshEnums.h"

#include "Element.h"

Copy link

Collaborator Author

norihiro-w Jan 28, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed

endJunction reviewed Feb 2, 2015
View reviewed changes

Norihiro Watanabe and others added 21 commits February 9, 2015 17:20

use 2nd version of calcTetrahedronVolume() in mesh element implementa…

6b295a6

…tions

have default value of element id and value only in TemplateElement

c6faee2

correct documentation

1f4e0ca

remove duplicated testElementNodeOder() in CellRule

1216e6e

move dimension constant to Edge,Face,Cell. delete unused

58ae9c1

move n_face of 2D elements to FaceRule

6381fca

correct schematics for the higher order elements

f04f3fe

optimise getFace() for Hex and Tet as the number of face nodes is alw…

8191089

…ays same

deactivate definitions of statict const variables on MSVC

5d84ddb

rename DummyEdgeReturn to NoEdgeReturn

47d8f67

delete unused const

19748a9

remove unnecessary definitions of const static variables

6cab232

correct spels and schematic

4ca6ea6

delete unused header

59183c9

[MeL] Remove unused include.

d07b4a2

make Element::getEdge() pure virtual

300dbac

Merge pull request #35 from endJunction/new-imp-ele

5186d9f

[MeL] Remove unused include.

add missing include in TestPntInElement

41d7d01

include Element instead of Face in Mesh2MeshPropertyInterpolation

3bbf328

remove Edge, Face, and Cell and add similar as rules

b169338

remove unnecessary T_BASE template parameter from TemplateElement

591e70c

norihiro-w force-pushed the new-imp-ele branch from bace3bb to 591e70c Compare February 9, 2015 16:20

endJunction added a commit that referenced this pull request Feb 10, 2015

Merge pull request #572 from norihiro-w/new-imp-ele

1016cda

[MeL] Replacement of element classes with TemplateElement<Rule>

endJunction merged commit 1016cda into ufz:master Feb 10, 2015

norihiro-w deleted the new-imp-ele branch February 24, 2015 14:02

endJunction removed the please review label Jul 6, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[MeshLib] Replacement of element classes with new implementation using TemplateElement #572

[MeshLib] Replacement of element classes with new implementation using TemplateElement #572

norihiro-w commented Jan 26, 2015

wenqing Jan 26, 2015

norihiro-w Jan 26, 2015

TomFischer Jan 27, 2015

wenqing Jan 27, 2015

rinkk Jan 27, 2015

wenqing commented Jan 26, 2015

TomFischer Jan 27, 2015

norihiro-w Jan 27, 2015

rinkk Jan 27, 2015

norihiro-w Jan 27, 2015

rinkk Jan 27, 2015

rinkk commented Jan 27, 2015

rinkk commented Jan 27, 2015

norihiro-w commented Jan 27, 2015

rinkk commented Jan 27, 2015

norihiro-w Jan 27, 2015

norihiro-w commented Jan 28, 2015

norihiro-w Jan 28, 2015

norihiro-w commented Jan 30, 2015

endJunction Feb 2, 2015

norihiro-w Feb 3, 2015

rinkk Feb 4, 2015

norihiro-w commented Feb 9, 2015

endJunction commented Feb 9, 2015

bilke commented Feb 10, 2015

ogsbot commented Jun 19, 2020

[MeshLib] Replacement of element classes with new implementation using TemplateElement #572

[MeshLib] Replacement of element classes with new implementation using TemplateElement #572

Conversation

norihiro-w commented Jan 26, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wenqing commented Jan 26, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rinkk commented Jan 27, 2015

rinkk commented Jan 27, 2015

norihiro-w commented Jan 27, 2015

rinkk commented Jan 27, 2015

Choose a reason for hiding this comment

norihiro-w commented Jan 28, 2015

Choose a reason for hiding this comment

norihiro-w commented Jan 30, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

norihiro-w commented Feb 9, 2015

endJunction commented Feb 9, 2015

bilke commented Feb 10, 2015

ogsbot commented Jun 19, 2020