I have noticed some strange behavior when I use a varf to create a real[int] in PETSc, and I’m not sure if this is a bug or my own misunderstanding. Please see that attached MWE (I’ve added some explainer text that will print via cout when the script is run). Note that the discrepancies referred to in this script are tiny, but in my actual application, the discrepancies are resulting in a division by 0. I imagine this must have something to do with ghost cell values? Any insight will be helpful!
$ ff-mpirun -n 4 test.edp -v 0
CASE 1: serial (w/o PETSc)
value 0 = 0.41000000000000031
value 1 = 0.41000000000000031
value 2 = 0.41000000000000031
All values are equal.
CASE 2: with PETSc
value 0 = 0.41000000000007553
value 1 = 0.41000000000000031
value 2 = 0.41000000000000031
I understand why value 0 and value 1 may not be equal...
But why does value 1 not equal value 2 in case 2 (even with 1 proc)?
Thanks, Pierre. I will try to come up with a better MWE this afternoon. In my problem, I was using a direct solver.
In the meantime, can you see any reason why a real[int] constructed from varf1(where the test function is written into the form AND BC) might not be equal to one built from varf2 (where the test function only appears in the BC)? Of course, I’m referring to a case where the test function does not change between these two situations.
I would expect all of these to vec to be equal (within machine precision). However, I find that, while vec0 and vec2 are equal, vec1 is different (it is zero). Am I doing something wrong/is that expected?