On Friday, August 12, 2016 at 4:05:33 PM UTC-7, Daniel Arndt wrote: > > Bruce, > > > >> The p_local_solution vector is filled with values as the result of >> solving a linear equation, p_local_rho is filled with values by looping >> over individual elements and assigning values calculated from other >> quantities. Part of the reason the p_local_rho vector doesn't have ghost >> nodes is that you can't access individual elements for a ghosted vector. >> > You can't write to a ghosted vector, but you can read from it. Is this > what you mean? >
My impression was that you can use the [] operator on ghosted vector, i.e. using something like p_local_solution[i] (for a ghosted vector) in either an access or assignment statement throws and error. Although, now that I'm looking through the code with fresh eyes, it looks like p_local_solution(i) does work, at least for accesses. The DataOut object appears to only handle ghosted vectors. It also appears >> that you need to call ompress on non-ghosted vectors (this was determined >> empirically based on error messages). >> > Yes, for proper output you should use ghosted vectors that store the > solution on all the dofs of locally owned cells. If you modify a parallel > vector you have to call compress as mentioned in step-40 [1] for example. > Would you want to have this information at some different place as well. If > yes, where? > I guess I was under the impression that you only had to do compress on a ghosted vector, but I'm not sure where I got that idea. I think it might be useful to have a general description of distributed vectors that clarifies ghosted/non-ghosted, what happens when you call compress for both ghosted/non-ghosted vectors (and what is happening when you choose insert versus add), and how you can trigger a ghost element update. The exact role of compress is hard to fathom, since if you already have a distributed vector without ghost cells and you modify local elements, it is hard to see what else needs to happen before the vector is ready for use (maybe just get rid of an internal flag that marks the vector as "modified"?). Also, I seem to run into problems where I could call compress with an insert argument, but not an add argument. Again, it is not clear to me what the distinction is. The current documentation says: In short, you need to call compress() in the following cases (and only in those cases, though calling compress() in other cases just costs some performance): 1. At the end of your assembly loop on matrices and vectors. This needs to be done if you write entries directly or if you use *ConstraintMatrix::distribute_local_to_global* <https://www.dealii.org/8.4.1/doxygen/deal.II/classConstraintMatrix.html#aa9f3612a8fc51eafa34252bb436e8ae4>. Use VectorOperation::add. 2. When you are done setting individual elements in a matrix/vector before any other operations are done (adding to elements, other operations like scaling, solving, reading, etc.). Use VectorOperation::insert. 3. Like in 2., but for adding values to individual elements. Use VectorOperation::add. I guess 3) is obscure. Does this mean that you are adding a new element where none existed before or that you are incrementing an existing element? If the former, aren't the total number of elements in a vector specified when you declare the vector size so how do you add more elements? I'm not sure I have any great ideas about where to put this. Adding a section to the glossary under "Distributed Vectors and Matrices" might be one possibility. Another might be to create a standalone document on Distributed Data Structures for Parallel Computing that could give an overview of the DEAL II parallel programming model > The vecScale function is just designed to multiply all values of an >> un-ghosted vector by a constant. >> > You could also use operator*= [2] for this. > Using this function seems to solve the problem. Not sure why the other version doesn't work, but this does the trick. If you don't change the values of the vectors using vecScale then the data >> for "Phi" and "Rho" appears smooth (but the scale is unwieldy). If you >> change the values of the vectors using vecScale, then "Phi" looks okay but >> "Rho" appears to have unscaled values at locations that look like they are >> at processor boundaries. I'm puzzled about how this is happening, since my >> understanding is that a data exchange happens when you do the assignment >> rho = p_local_rho. The vecScale function only operates on un-ghosted >> vectors, but is it possible that it is missing some values somewhere? >> > This sounds weird as you do the exact same thing to (rho, p_local_rho) and > (p_local_solution, phi). So you observe that p_local_solution looks wrong > as well? Do you have a minimal working example showing this problem? > The results coming from p_local_solution look good (smooth) and appear to have been scaled, only the results for p_local_rho have a problem. I've tried to create a simple reproducer but so far haven't had any success. I'll keep trying. Bruce > > Best, > Daniel > > [1] > https://dealii.org/8.4.0/doxygen/deal.II/step_40.html#LaplaceProblemassemble_system > > [2] > https://www.dealii.org/8.4.0/doxygen/deal.II/classPETScWrappers_1_1VectorBase.html#a37900779c6049418c39bacc1d44f4260 > > <https://www.google.com/url?q=https%3A%2F%2Fwww.dealii.org%2F8.4.0%2Fdoxygen%2Fdeal.II%2FclassPETScWrappers_1_1VectorBase.html%23a37900779c6049418c39bacc1d44f4260&sa=D&sntz=1&usg=AFQjCNH3GR4UgKaoRxMTBB2cWBCkaihnxQ> > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
