Question on MARKER_INTERNAL

[koodlyakshay]

Hello all,

I have a question about using the MARKER_INTERNAL. I was expecting that adding a MARKER_INTERNAL will not affect the solution in any way. Though, when I try to use it I observe a spurious spike in the solution at the location of the internal marker.

To create an interior marker in Pointwise, I create a baffle zone which connects two blocks (https://www.pointwise.com/doc/user-manual/cae/set-boundary-conditions/boundary-condition-connections.html). So there are two sides of the face and I marked them both as internal markers. This increases the number of elements in mesh because the nodes on the marker are duplicated (one for each side except on the perimeter). So essentially, at the each (x,y,z) location of the internal marker, there are two nodes. Instead of having 6 neighbors as an internal node (hex elements in 3-D), the two nodes "share" the neighbors which leads to error in momentum and mass balance in both the nodes causing errors in the solution.

I am not quite sure how to fix this. Is there a different way to use internal markers? Or is the internal marker not supported anymore?

Regards,
Akshay

[auzbaig]

You should be able to link the two faces in Pointwise. Then Pointwise will make a connection for you and you won't have to name an extra unspecified marker. Usually Pointwise does this automatically, make sure you have the sufficient tolerance set in Pointwise if you are importing your mesh from somewhere else.
You do not need to name the connections.

[koodlyakshay]

Hi,
The two faces are indeed linked and I think that is causing the problem. I should have attached an example in the question. Sorry about that. Anyway here are two very coarse meshes that I have been playing around with - one with an internal marker and one without.
case_example.zip

The domain is fairly straight forward and is a box of length 5 units in x direction and 2 units each in y and z directions. The bottom face is treated like a wall, so this is essentially a flat plate with the flow along x direction. I expect the to get the same solution with and without internal markers, but that is not the case. Here is the centerline velocity along the domain with (blue line) and without (brown line) internal marker. The internal marker is located at x=-0.625.

Cheers

[auzbaig]

Why are you defining an internal marker? I always try to avoid having undefined faces in my mesh.

If you are linking the face your connectivity will be different than when you are not linking the faces. I don't know how Pointwise does it, but that's my guess.

[auzbaig]

As for what an internal marker actually does, someone else can answer it better.

[koodlyakshay]

Why are you defining an internal marker?

Haha. Initially, I thought by creating a dummy marker inside my domain and calling it "INTERNAL", I can output solution at any desired face in the solution_flow file without having to deal with post processing software. This is of course possible in Paraview or Tecplot, but I figured this may be more automatic and perhaps easier especially with curved surfaces.

Now I am simply curious as to what is happening with the internal markers.

[pcarruscag]

I think marker internal is a "do-nothing" marker as you expect, at least so far as boundary conditions go. Try this example.zip I put an internal marker across a channel flow and everything seems to work fine.
You are probably having issues because you duplicated the nodes. i.e. you created an actual disjoint boundary instead of just a collection of internal faces.

I would make triple sure this does not influence your solution, an obscure feature like this is almost guaranteed not to be compatible with all corners of SU2...

[economon]

Yep, @pcarruscag is right. When defined correctly, the internal marker should do nothing and only serve for output reasons (that was the original intention). You can use it for defining surface integrals as objective functions, for instance (uniformity, mass-avg. quantities, etc.).

Do double check that the surfaces have been merged into one: only one definition of each node and face on the boundary.

[koodlyakshay]

I tried the case from @pcarruscag and it indeed works. However, when I extrude the same mesh to 3-D by 5 cells in Pointwise I don't see the correct solution. I created the new interior face by dividing the existing mesh in the middle to avoid any tolerance issues when joining two disjoint meshes. I don't see any issues with mesh quality. Even though only one surface exists. the nodes are duplicated, but that is how Pointwise writes the mesh file when creating an internal face in 3D. If I try to avoid this duplication, there is an additional unspecified marker written. This duplication happens only on the interior of the face and not on the perimeter of the marker.

Also, I found this forum post about nodes being written twice(https://www.cfd-online.com/Forums/pointwise/171862-excluding-domain-boundaries-getting-written-twice.html) and it appears that Pointwise always writes duplicate nodes when exporting meshes with internal boundary markers. I am not quite sure if this now a Pointwise issue or SU2 one anymore.

[auzbaig]

When you create another boundary do you create a new unspecified marker or do you use the connections as a marker? In the former case, the connectivity will be affected, as the nodes at the interface should be linked. However, if you use the connection as an additional marker, it should work.

[pcarruscag]

I am not quite sure if this now a Pointwise issue or SU2 one anymore.

It's not a bug, it's a feature, for both codes :)

[koodlyakshay]

I use the connection as the additional marker. Since the connection is two sided, nodes are duplicated. This is quote from the forum post I linked earlier

....creates unique (yet coincident) points for each "side" of the domain....

The quote was about Gmsh exporter and not SU2, but later on they say this is the case for all exporters except Fluent. These duplicated nodes affect the mass and momentum balance because they each carry information about the neighbors on their respective side only.

This might not be a problem if we were to apply a strong boundary condition like a wall because the dirichlet condition will simply overwrite any residuals and apply the appropriate value to both the nodes. However when used as an internal marker or any other weak boundary condition, the duplicate nodes each carry part of the residuals and if they don't communicate with each other an imbalance will occur. At the moment, it appears they do not communicate with each other.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions.