On 03/16/2015 02:49 PM, Bård Skaflestad wrote: > On 26/01/15 13:00, Jørgen Kvalsvik wrote: >> Hi, > > Hi, > > Sorry about the delay. I was just going through my old e-mail and > noticed that I didn't see an answer to this question. I'll provide one > for the mailing list record, even it much time has passed since the > question was posed. Thanks, appreciate it.
>> Can the Dirichlet and periodic facetypes alternate within the same >> matrix, or are they mutually exclusive? If they are exclusive using a >> vector of facevalues really doesn't make sense (nor does the switch). > > These face types can definitely appear within the same problem. One > typical case would be an upscaling problem that uses periodic pressure > drop in one cardinal direction, for instance along the X axis, and a > constant pressure drop in another cardinal direction--for instance along > the Y axis. That might be a strange configuration from an end-user > application point of view, but it is nevertheless possible and we have > to allow for the situation. Ok, good to know. I might add this as a comment just for clarification. >> The l2g values, are they contiguous? > No, they are not. Basically, L2G plays the role of the traditional > local-to-global mapping degrees of freedom in implementations of finite > element methods. In other words > > l2g[i] > > is the global identity of the i-th local degree of freedom. Ok. I might add this as a comment too, as it is an underlying assumption it is nice to have clear. >> In the periodic case, will some indices be encountered twice? > > I'm not sure I understand the question. All indices may, and typically > will, be encountered multiple times in the assembly stage. Ok, this is also a nice-to-know assumption, because it dictates how you can assemble. The reason I asked is because I want to separate matrix construction and assembly from matrix usage (seeing as they with benefits can be considered two completely different structures), and I only wanted to support direct, overwriting insertion. I broke the problem down a bit further and now support both insertion (matrix[i][j] = x) and accumulation (matrix[i][j] += x), in order to support the construction phase as a "staging ground" for cell values. The fact that some indices may be encountered more than once means that either this must be pre-computed, essentially requiring a redundant assembly phase or support partially completed values during assembly. > The >> comments say a*(x0-x1) = a*(pd) etc with no reference to a, but implies >> this should be computable with an assignment, not +=. > > That comment outlines the type of the linear equation, or rather, > contribution, being assembled in the periodic case. In this case, 'a' > is a coefficient, 'x0', and 'x1', are degrees of freedom, and 'pd' is > the prescribed periodic pressure drop. We are specifically not talking > about C++ implementation at that point. Great. I might add something to clarify this as well. >> Finally, and if this has a good answer then ignore the three questions >> above: is there a better way to formulate this in terms of matrix >> operations? Right now it is quite hands-on update-individual-cells, but >> I would like a more math-oriented algorithm. e.g. in the case of >> dirichlet it basically reduces to finding diagonal segments of the >> SharedFortranMatrix and assigning them to (maybe contiguous) diagonals >> in S_. > > Class IncompFlowSolverHybrid<> implements a fairly standard assembly of > a system of simultaneous linear equations with contributions for each > cell being sequentially added to the coefficient matrix and right hand > sides. The process is very much inspired by traditional finite-element > software. If there is a better approach, then I'd like to see it. I might play around with a modified scheme if I find the time, but I must first see how the IncompFlowSolverHybrid is called and how much other code must be modified for it to work. Personally I would like to break it up a little bit more - it feels slightly monolithic. Thanks for your time and a great answer! - Jørgen
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
