June 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Satish Balay 06 Jun '12

06 Jun '12

On Wed, 6 Jun 2012, Jed Brown wrote: > On Wed, Jun 6, 2012 at 6:41 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise > > how would you know it's there > > > > Stop right there. So you are saying if I just run in petsc-dev: hg > > pull -u it will NOT pull and update in BuildSystem? > > Just want to clarify the 'subrepo' model: subrepo is not emulating 'a single repo' usage with multiple repos. [single repo model is best done with a single repo :)] Subrepo model is letting us track other repos [i.e subrepo] changes in the primary repo commits. [similar to how file changes are tracked in the primary repo commits]. However the difference is: file changes are registered as 'diffs' in the primary repo commits. The 'subrepo' changes are registered as a 'primary-repo-commit-id -> sub-repo-commit-id' relations in the .hgsubstate file in the primary-repo. Some hg commands can use this info to act on both repos. Others dont. Satish > > It will pull up to the last revision of BuildSystem that has been marked. > If someone goes off and updates BuildSystem externally, it will not > automatically pull that. But I assert that you don't actually want that. If > it was actually updated externally (like anything that is legitimately a > different project), *some* petsc developer should be certifying that new > revision is correct. > > Of course this step is not needed if we are making the update in tree. In > that case, you just commit and push from petsc and the buildsystem commits > will be done for you. > > Specifically > > ~/petsc-dev$ emacs config/BuildSystem/config/framework/config/framework.py > ~/petsc-dev$ hg commit --subrepos -m'framing work' # commits in both > config/BuildSystem and petsc-dev > > You can use -S = --subrepos or add it to your alias. > > An alternative: > > ~/petsc-dev$ hg -R config/BuildSystem commit -m"Add something to > buildsystem, but don't publish to petsc-dev" > ... do other things in petsc-dev, maybe update something dependent > ~/petsc-dev$ hg commit -m"Add thing that depends on buildsystem's > 'something' patch, but has a different commit message" > > This second commit will include the new .hgsubstate. It will be pushed and > pulled automatically. > > > > > > > What if in petsc-dev I do: hg commit; hg push. Will that or will > > that not commit and push all the changes I made in the BuildSystem ? Or > > will it ignore the changes I made in BuildSystem? Or will it put those > > changes into the petsc-dev repository and not the BuildSystem repository > > (so Matt won't get my cool changes I made to BuildSystem)? > > > > Something in config/BuildSystem will never go into the petsc-dev > repository, always the BuildSystem repository. > > Your pulls and pushes are recursive by default. If you want commit to be > recursive by default (instead of needing the -S flag to recurse into > subrepos), you can set that in your .hgrc. If you make -S default, it will > still only make a BuildSystem commit if something changed there, so it's > relatively harmless (as long as you want to use the same commit message for > a fix to BuildSystem as for the dependent patch in petsc-dev). > > > > > > What if I am in the BuildSystem directory and commit and push? Into what > > repository(ies) do my changes go? Does it matter what directory I am in > > what happens when I do hg commit etc? > > > > If you are in the BuildSystem directory, then you are working with the > BuildSystem repo independently from PETSc. The next time you commit from > the PETSc repo, it will sync up with the last commit visible in > config/BuildSystem. > > > > > > I think Satish proved a few months ago the subrep concept made no sense > > with our petsc-dev and BuildSystem workflows. So why are you guys > > revisiting it since you haven't improved the inadequate subrep model since > > then? > > > > Please explain our work flow under the subrepo model where any of us are > > making changes in petsc-dev and BuildSystem (as part of petsc-dev) > > meanwhile people may also be making changes to BuildSystem. > > > > In normal workflow, you can just always commit with the -S switch (even add > it to your .hgrc) from the PETSc repository. It will automatically include > a commit to BuildSystem when it's necessary and will always be synced. > > If you make some BuildSystem commits while someone pushes their own > upstream without touching the petsc repository, your push will be rejected > (just like with any repository) and you should pull the updates for > BuildSystem, merge, and commit. > > > > > > Note: don't think I am opposed to resolving the bisection problem, I am > > just opposed to "fixing it" if it totally breaks our everyday work flows. >

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Satish Balay 06 Jun '12

06 Jun '12

On Wed, 6 Jun 2012, Barry Smith wrote: > Satish, > > You will not just "recheck this". Please setup the petsc-buildsystem-dev test repository so EVERYONE can test it and make sure there are no kinks. Added. ssh://[email protected]//home/petsc/petsc-buildsystem-dev Just to clarify - this is a play-repo - i.e all edits/clones should be discarded later on. [I'm not sure how one would enforce this - and not have someone mix commits between this repo and the regular petsc-dev So for now its not available at http://] Satish ---------

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 6:41 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise > how would you know it's there > > Stop right there. So you are saying if I just run in petsc-dev: hg > pull -u it will NOT pull and update in BuildSystem? > It will pull up to the last revision of BuildSystem that has been marked. If someone goes off and updates BuildSystem externally, it will not automatically pull that. But I assert that you don't actually want that. If it was actually updated externally (like anything that is legitimately a different project), *some* petsc developer should be certifying that new revision is correct. Of course this step is not needed if we are making the update in tree. In that case, you just commit and push from petsc and the buildsystem commits will be done for you. Specifically ~/petsc-dev$ emacs config/BuildSystem/config/framework/config/framework.py ~/petsc-dev$ hg commit --subrepos -m'framing work' # commits in both config/BuildSystem and petsc-dev You can use -S = --subrepos or add it to your alias. An alternative: ~/petsc-dev$ hg -R config/BuildSystem commit -m"Add something to buildsystem, but don't publish to petsc-dev" ... do other things in petsc-dev, maybe update something dependent ~/petsc-dev$ hg commit -m"Add thing that depends on buildsystem's 'something' patch, but has a different commit message" This second commit will include the new .hgsubstate. It will be pushed and pulled automatically. > > What if in petsc-dev I do: hg commit; hg push. Will that or will > that not commit and push all the changes I made in the BuildSystem ? Or > will it ignore the changes I made in BuildSystem? Or will it put those > changes into the petsc-dev repository and not the BuildSystem repository > (so Matt won't get my cool changes I made to BuildSystem)? > Something in config/BuildSystem will never go into the petsc-dev repository, always the BuildSystem repository. Your pulls and pushes are recursive by default. If you want commit to be recursive by default (instead of needing the -S flag to recurse into subrepos), you can set that in your .hgrc. If you make -S default, it will still only make a BuildSystem commit if something changed there, so it's relatively harmless (as long as you want to use the same commit message for a fix to BuildSystem as for the dependent patch in petsc-dev). > > What if I am in the BuildSystem directory and commit and push? Into what > repository(ies) do my changes go? Does it matter what directory I am in > what happens when I do hg commit etc? > If you are in the BuildSystem directory, then you are working with the BuildSystem repo independently from PETSc. The next time you commit from the PETSc repo, it will sync up with the last commit visible in config/BuildSystem. > > I think Satish proved a few months ago the subrep concept made no sense > with our petsc-dev and BuildSystem workflows. So why are you guys > revisiting it since you haven't improved the inadequate subrep model since > then? > > Please explain our work flow under the subrepo model where any of us are > making changes in petsc-dev and BuildSystem (as part of petsc-dev) > meanwhile people may also be making changes to BuildSystem. > In normal workflow, you can just always commit with the -S switch (even add it to your .hgrc) from the PETSc repository. It will automatically include a commit to BuildSystem when it's necessary and will always be synced. If you make some BuildSystem commits while someone pushes their own upstream without touching the petsc repository, your push will be rejected (just like with any repository) and you should pull the updates for BuildSystem, merge, and commit. > > Note: don't think I am opposed to resolving the bisection problem, I am > just opposed to "fixing it" if it totally breaks our everyday work flows.

1 0

Re: [petsc-dev] PCFieldSplitSetFields() API change
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 6:54 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > No you don't get back a pair of subDMS, you get a DM that goes from one > state space to "a different" residual space. Normally one would not need > this though it does come up in the VI stuff. > For a low temperature/rarefied gas, total energy and density (residuals in two of your conservation equations) are nearly parallel and point in a very different direction from the primitive variables pressure and energy. (Never mind that primitive variables would be a very bad formulation here.) For high temperature and low velocity, total energy is essentially proportional to pressure and density is proportional to p/T. The point here is that in different nonlinear regimes, the conditioning of a given diagonal block can change substantially. You could say that one should just choose conservative variables so that at least the residual and the state use the same units, but that produces a very ill-conditioned basis in the low-Mach limit. > > The reason this works for PCASM is that we demand that the input/output > spaces are nested (e.g., the output space for RASM is a subspace of the > input). > > Actually RASM has an option where the output space is larger than the > input space. (The subproblems are defined as extending the right hand side > by zero, solving the subproblem and then keeping the entire solution (on > the overlapped region). > Well, I'm not sure that it makes sense to express RAS and ASH (AS with harmonic extension) that way. For example, DMCreateMatrix() for that problem needs to address the whole overlapping space. You solve it by restricting the input or restricting the output, but the mechanics of the solve needs the whole overlapping region.

1 0

Re: [petsc-dev] Viewing MPI matrices
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 6:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > A better solution is to fix the parallel views for ASCII to print things > properly with the right number of processes etc directly rather than > calling the sequential views. What about pushing a NO_HEADER attribute on the viewer before calling the sequential view?

1 0

Re: [petsc-dev] Viewing MPI matrices
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 5:18 PM, Dmitry Karpeev wrote: > When viewing a MATMPIAIJ on a communicator of size>1, one can see something like this (in an ASCII viewer): > Matrix Object: 1 MPI processes > type: mpiaij > row 0: (0, -8.32667e-17 + 0.4 i) (1, -1) (2, -1) > row 1: (0, -1) (1, -8.32667e-17 + 0.4 i) (3, -1) (8, -1) > row 2: (0, -1) (2, -8.32667e-17 + 0.4 i) (3, -1) (4, -1) > > That may be a bit confusing, since the matrix one is trying to view has more than 1 ranks. > This is, of course, the result of the way MatView is implemented: pull the distributed matrix into an MPIAIJ > that lives on a communicator of size 1 containing the rank 0 of the original comm, then view that auxiliary matrix. > Should we try to print the original comm size here, instead of "1 MPI processes"? That can be easily done by > composing the original matrix with the auxiliary one and extracting it to check the comm size in MatView_SeqXXX. > Alternatively, we could attach just the original comm size to the auxiliary Mat. > Or am I the only one bothered by this? I don't like "making MatView_SeqAIJ() for ASCII all complicated and knowing about parallel matrices" as the solution to the "problem." A better solution is to fix the parallel views for ASCII to print things properly with the right number of processes etc directly rather than calling the sequential views. Barry > > Dmitry. >

1 0

Re: [petsc-dev] PCFieldSplitSetFields() API change
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 5:16 PM, Dmitry Karpeev wrote: > > > On Wed, Jun 6, 2012 at 4:58 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 23, 2012, at 6:22 PM, Jed Brown wrote: > > > But what does using B as 00 block actually mean? It seems to me that you pivot, producing P' P J where P J has B in the 00 location. > > I am not arguing if it is pivoting or not. I'm arguing what the user interface should be. Say I want D to be the 00 block then I just set that with PCFieldSplitSetFields() as the zeroth field. My point is that I am proposing a SINGLE interface for setting the blocks locations in all circumstances, while you are proposing having an additional interface for certain 00 configurations (pivoting) thus with your model you first call the PCFieldSplitSetFields() and then something else. > > I just talked about this more with Dmitry. > > It seems that we need to name both the row and column spaces of the operator. > The reason is that we need to be able to address the subproblem (e.g., from the command-line to dial its solver options), not the individual row (output) or col (input) fields. And a subproblem, by definition, involves an input-output (col-row) pair. > Further, if we wanted to recursively split/domain-decompose/coarsen the subproblem, we might want to associate a subDM with it. If we associated subDMs with each row and col split, a subproblem would end up with a pair of subDMs, which wouldn't be all that useful. No you don't get back a pair of subDMS, you get a DM that goes from one state space to "a different" residual space. Normally one would not need this though it does come up in the VI stuff. > > Which begs the question: what is DM? Is it a distribution of the state space (column space for a linear operator), a distribution of the residual space (row space), or both? If both, we should make it possible to select arbitrary pairs. > A DM, in my view, should a "(sub)problem", which can be solved, hence, implicitly, is square. I am not sure if this will be right in the long run; it need not be square (for example least squares solve?). > Further, as currently implemented, a DM uses the same distribution for solutions and residuals (since there is only one DMCreateGlobalVector()). This actually works for PCFieldSplit, because the implied meaning of a field split is a nodewise split of the degrees of freedom over some background mesh, with the distribution of nodes determining the dof distribution. Just like MatGetVecs() actually returns left and right vectors we may need to change DM to return left and right vecs. > The reason this works for PCASM is that we demand that the input/output spaces are nested (e.g., the output space for RASM is a subspace of the input). Actually RASM has an option where the output space is larger than the input space. (The subproblems are defined as extending the right hand side by zero, solving the subproblem and then keeping the entire solution (on the overlapped region). > I don't know whether we want to generalize away from it. Even within the current DM model it defines a subproblem that can be used in FieldSplit and ASM. All we have to do, if we are to stick with this, is make sure that the local sizes match for the ISs in the pair defining a subproblem. > > Dmitry. > > >

1 0

Re: [petsc-dev] PCFieldSplitSetFields() API change
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 4:58 PM, Jed Brown wrote: > On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 23, 2012, at 6:22 PM, Jed Brown wrote: > > > But what does using B as 00 block actually mean? It seems to me that you pivot, producing P' P J where P J has B in the 00 location. > > I am not arguing if it is pivoting or not. I'm arguing what the user interface should be. Say I want D to be the 00 block then I just set that with PCFieldSplitSetFields() as the zeroth field. My point is that I am proposing a SINGLE interface for setting the blocks locations in all circumstances, while you are proposing having an additional interface for certain 00 configurations (pivoting) thus with your model you first call the PCFieldSplitSetFields() and then something else. > > I just talked about this more with Dmitry. > > It seems that we need to name both the row and column spaces of the operator. Which begs the question: what is DM? Is it a distribution of the state space (column space for a linear operator), a distribution of the residual space (row space), or both? If both, we should make it possible to select arbitrary pairs. Yup. Yet not too long ago when I advocated this you strongly objected and said it was totally unnecessary. I'm glad Dmitry was able to straighten you out.. Barry

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 4:38 PM, Jed Brown wrote: > On Wed, Jun 6, 2012 at 4:35 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > "you commit to petsc-dev " > > Show me the EXACT syntax you use to "commit to petsc-dev" and I'll show you something stupid that no one will use. > > $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise how would you know it's there Stop right there. So you are saying if I just run in petsc-dev: hg pull -u it will NOT pull and update in BuildSystem? What if in petsc-dev I do: hg commit; hg push. Will that or will that not commit and push all the changes I made in the BuildSystem ? Or will it ignore the changes I made in BuildSystem? Or will it put those changes into the petsc-dev repository and not the BuildSystem repository (so Matt won't get my cool changes I made to BuildSystem)? What if I am in the BuildSystem directory and commit and push? Into what repository(ies) do my changes go? Does it matter what directory I am in what happens when I do hg commit etc? I think Satish proved a few months ago the subrep concept made no sense with our petsc-dev and BuildSystem workflows. So why are you guys revisiting it since you haven't improved the inadequate subrep model since then? Please explain our work flow under the subrepo model where any of us are making changes in petsc-dev and BuildSystem (as part of petsc-dev) meanwhile people may also be making changes to BuildSystem. Note: don't think I am opposed to resolving the bisection problem, I am just opposed to "fixing it" if it totally breaks our everyday work flows. Barry > $ hg commit -m'cool stuff in BuildSystem' >

1 0

Re: [petsc-dev] Use of PETSc in real-time applications
by Aron Ahmadia 06 Jun '12

06 Jun '12

A. J. Ahmadia and B. L. Ellerbroek, " A Software Framework for Fast Adaptive Optics Control with Atmospheric Tomography," http://www.opticsinfobase.org/abstract.cfm?URI=AO-2005-AThB4 On Thu, Jun 7, 2012 at 12:39 AM, Shrirang Abhyankar <abhyshr(a)mcs.anl.gov> wrote: > Thanks Jed. > > On Jun 6, 2012, at 5:33 PM, Jed Brown wrote: > > @article{akcelik2005ddd, > title={{Dynamic data-driven inversion for terascale simulations: real-time > identification of airborne contaminants}}, > author={Ak\c{c}elik, V. and Biros, G. and Draganescu, A. and Hill, J. and > Ghattas, O. and van Bloemen Waanders, B.}, > journal={Proceedings of the 2005 ACM/IEEE conference on Supercomputing}, > year={2005}, > publisher={IEEE Computer Society Washington, DC, USA} > } > > On Wed, Jun 6, 2012 at 5:21 PM, Shri <abhyshr(a)mcs.anl.gov> wrote: >> >> Hi, >> I'm trying to compile a list of real-time applications using PETSc. Three >> applications are listed on the PETSc applications page. >> >> Computational Infrastructure for the Real-Time Patient-Specific Treatment >> of Cancer, K. R. Diller, J. T. Oden, C. Bajaj, J. C. Browne, J. Hazle, I. >> Babu{\vs}ka, J. Bass, L. Bidaut, L. Demkowicz, A. Elliott, Y. Feng, D. >> Fuentes, S. Goswami, A. Hawkins, S. Khoshnevis, B. Kwon, S. Prudhomme, and >> R. J. Stafford, University of Texas at Austin, 2008 (link broken) >> >> Real-Time Registration of Volumetic Brain MRI by Biomechanical Simulation >> of Deformation during Image Guided Neurosurgery, Simon K. Warfield, Florin >> Talos, Alida Tei, Arya Nabavi, Matthieu Ferrant, Peter McL. Black, Ferenc A. >> Jolesz, and Ron Kikinis, Computing and Visualization in Science, 2002. (link >> broken) >> >> Real-Time Biomechanical Simulation of Volumetric Brain Deformation for >> Image Guided Neurosurgery, Simon K. Warfield, Matthieu Ferrant, Xavier >> Gallez, Arya Nabavi, Ferenc A. Jolesz, and Ron Kikinis, Proceedings of >> SC2000, 2000. >> >> Please let me know if there are any more. >> >> Thanks, >> Shri > > >

1 0