Hi Edscott, > On 6. Dec 2018, at 18:45, Ed Scott Wilson Garcia <edsc...@imp.mx> wrote: > > Say we are dealing with a 2 dimensional square domain, on regular grid, top > corner at (XMax, YMax). We can set the boundary condition type with the > problem function "boundaryTypesAtPos(BoundaryTypes &, const GlobalPosition > &)". When using the box method, the values in GlobalPosition correspond to > the nodes of the user input grid.
This is correct. You need to set a boundary condition for every boundary node. > > Thus, when determining the boundary type condition, the function will be > called with (0,0), (0,YMax), (YMax,0) and (XMax,YMax). > > If we have Dirichlet conditions on segment (0,0)-(XMax,0) and on segment > (0,YMax)-(XMax,YMax) and Neuman on the other two borders, there is an > apparent issue on type determination. > > Take the behavior of the function when GlobalPosition is (0,0). If the size > of the subcontrol volume is L (element size 2L), then we have segments > (0,0)-(0,L) and (0,0)-(L,0) to consider. > > If our code reads: > > if (globalPos[0] < epsilon) values.setDirichlet(idx1); > if (globalPos[1] < epsilon) values.setNeumann(idx1); > > Both segments will end up with Neumann, which is not right. I don’t see what is "not right" here. You get exactly what your code specifies. Both if conditions are satisfied on the corner node so setNeumann overwrites the setDirichlet. > But if we change the order in which > the logical instruction is executed to: > > if (globalPos[1] < epsilon) values.setNeumann(idx1); > if (globalPos[0] < epsilon) values.setDirichlet(idx1); > > Both segments will be assigned a Dirichlet type condition. The confusion > will also occur at the other three corners of the square domain. Again you get exactly what you specified. I don’t see the problem. In order to make your code less confusing you could use if/else constructs, or simply make sure that every node just satisfies one of your conditions. > > This may seem a minor issue, but in the geomechanics problems (the ones not > using pdelab in 2.12) the order in which the condition types are specified > has led to a singular matrix for the Newton iteration. Reversing the order > allows the method to converge in some cases. In other geomechanical problems > we cannot get the Newton method to converge, so we suspect the describe > boundary type confusion may be involved. > > Is there a way to solve this issue in the box method? Or would it be > necessary to use the cell centered method perhaps? From your description I can’t see what that issue would be. It can be tricky with the box method to define your boundary conditions sometimes, this is because it’s a formulation on a dual-grid, and you only have half-boxes on the boundary. Say, for instance, in a 2D rectangular domain, you want to make sure that no fluid leaves the top domain boundary (by setting Neumann 0), but you want to a piezometric head on the right boundary (Dirichlet). Then, if you set Dirichlet for the top right corner node, there is going to be one sub-control-volume-face adjacent to this node on the top boundary that you can’t control the flow over. So there might be leakage over that face in y-direction. On the other hand, if you set the corner node to Neumann there will be one sub-control-volume-face adjacent to the node on the right boundary that is also no-flow. This might be not what you want either, but it is usually better, and a possible error (because you don’t have the full right boundary available for flow) will decrease with grid refinement. This is inherent to the method being formulated on a dual grid. > > Any ideas or pointers, no matter how small, would be greatly appreciated. The convergence problem could come from multiple things. Why do you expect the boundary condition type of corner node to be the problem? It could be also related to which value you actually set on the boundary, if it fits your physical problem, time step size (for instationary problems),… Best regards, Timo > > > Best regards, > > Edscott > _______________________________________________ > Dumux mailing list > Dumux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux _______________________________________________ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
