March 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Reminder planning release soon
by Jed Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 10:05 AM, Paul Mullowney <paulm(a)txcorp.com> wrote: > Is my aijcusparse-icc branch going to get merged into next? Do I need to > do this? Do I have permissions? > Looking at our previous discussion, there were still a number of points that were commented on in the email thread, but not addressed. You didn't send an updated patch or a new pull request. I put what you had in a branch here, and fixed a couple more things. You should checkout this branch and make sure all points from the email thread have been addressed. Then push it to your fork and make a pull request. We'll comment on the pull request if anything else is needed, otherwise we'll merge it into 'next'. https://bitbucket.org/petsc/petsc/compare/pm/aijcusparse-icc..master#diff > Thanks, > -Paul > > This is a reminder that we are planning a release soon thus one >> should start testing and moving completed work over to the git next branch >> for nightly testing and then on to master. >> >> Barry >> >> >

1 0

Re: [petsc-dev] Unable to find zlib library
by Satish Balay 20 Mar '13

20 Mar '13

Make sure you have gcc/g++ from cygwin installed for sowing. Satish On Wed, 20 Mar 2013, Chen Shapira wrote: > Thanks Satish, > I've tried : > ./config/configure.py --with-cc='win32fe cl' --with-fc='win32fe ifort' > --with-cxx='win32fe cl' --with-mpi-dir="/cygdrive/C/Program Files > (x86)/MPICH2" --download-f-blas-lapack=1 --with-clanguage=c > --with-petsc-arch=arch-mswin-c-debug > --CFLAGS=-D_CRT_SECURE_NO_DEPRECATE --with-debugging=0 > --ignore-cygwin-link --with-valgrind=0 --with-c2html=0 > --download-sowing=1 --with-hdf5=1 > --with-hdf5-include=/cygdrive/c/libraries/hdf5/include > --with-hdf5-lib=\[/cygdrive/c/libraries/hdf5/libs/hdf5dll.lib,/cygdrive/c/libraries/hdf5/libs/hdf5_fortrandll.lib,/cygdrive/c/libraries/hdf5/libs/szip.lib,/cygdrive/c/libraries/hdf5/libs/zlib.lib\] > --LIBS=/cygdrive/c/libraries/hdf5/libs/zlib.lib > > and also with : --LIBS='/cygdrive/c/libraries/hdf5/libs/zlib.lib' > > and I got a different error : > Error running make; make install on Sowing (install manually): Could > not execute "cd /home/petsc-dev/externalpackages/sowing-1.1.16d && > make && make install && make clean": > (cd src/sys && make ) > make[1]: Entering directory > `/home/petsc-dev/externalpackages/sowing-1.1.16d/src/sys' > cl.exe -I../../include -I../../include -c arch.c > arch.c > arch.c(22) : fatal error C1083: Cannot open include file: > 'sys/utsname.h': No such file or directory > ../../Makerules:39: recipe for target `arch.o' failed > make[1]: Leaving directory > `/home/petsc-dev/externalpackages/sowing-1.1.16d/src/sys' > Makefile:18: recipe for target `libs' failed > > Thanks again > Chen > > On Tue, Mar 19, 2013 at 4:16 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > zlib detection code is a bit wired. Try using the additional option: > > > > > > LIBS=/cygdrive/c/libraries/hdf5/libs/zlib.lib > > > > Satish > > > > On Tue, 19 Mar 2013, Chen Shapira wrote: > > > >> Hi Again, > >> > >> While configuring PETSc in Cygwin, > >> I recieve the following error : > >> "Compression library [libz.a or equivalent] not found" > >> > >> The thing is, I already have the file : zlib.lib included in the > >> configuration of petsc . > >> > >> My configure command is : > >> ./config/configure.py --with-cc='win32fe cl' --with-fc='win32fe ifort' > >> --with-cxx='win32fe cl' --with-mpi-dir="/cygdrive/C/Program Files > >> (x86)/MPICH2" --download-f-blas-lapack=1 --with-clanguage=c > >> --with-petsc-arch=arch-mswin-c-debug > >> --CFLAGS=-D_CRT_SECURE_NO_DEPRECATE --with-debugging=0 > >> --ignore-cygwin-link --with-valgrind=0 --with-c2html=0 > >> --download-sowing=1 --with-hdf5=1 > >> --with-hdf5-include=/cygdrive/c/libraries/hdf5/include > >> --with-hdf5-lib=\[/cygdrive/c/libraries/hdf5/libs/hdf5dll.lib,/cygdrive/c/libraries/hdf5/libs/hdf5_fortrandll.lib,/cygdrive/c/libraries/hdf5/libs/szip.lib,/cygdrive/c/libraries/hdf5/libs/zlib.lib\] > >> > >> Thank you again.. > >> Chen > >> > > >

1 0

Re: [petsc-dev] Reminder planning release soon
by Barry Smith 20 Mar '13

20 Mar '13

On Mar 20, 2013, at 10:05 AM, Paul Mullowney <paulm(a)txcorp.com> wrote: > Is my aijcusparse-icc branch going to get merged into next? Do I need to do this? Do I have permissions? > Thanks, > -Paul Is it ready? You should make a pull request to merge it into next. https://bitbucket.org/petsc/petsc/wiki/pull-request-instructions-git or https://bitbucket.org/petsc/petsc/wiki/pull-request-instructions-mercurial (same as before) >> This is a reminder that we are planning a release soon thus one should start testing and moving completed work over to the git next branch for nightly testing and then on to master. >> >> Barry >> >

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Nystrom, William D 20 Mar '13

20 Mar '13

Hi Karli, I ran a test build last night and it failed. It was a relatively simple configuration where I was downloading mpich and cmake and building with threads, cuda and the txpetscgpu package. I was building on a Fedora 17 machine with Cuda 5. The failure seem to be associated with cmake. When I get home this evening, I could send you the configure and make logs. I did not have time this morning before leaving for work. I wanted to give you some early feedback even though the logs will have to wait till this evening. Thanks, Dave -- Dave Nystrom LANL HPC-5 Phone: 505-667-7913 Email: wdn(a)lanl.gov Smail: Mail Stop B272 Group HPC-5 Los Alamos National Laboratory Los Alamos, NM 87545 ________________________________________ From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] Sent: Tuesday, March 19, 2013 4:04 PM To: petsc-dev(a)mcs.anl.gov Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready Hi Dave, perfect, thanks! I should add that a reconfigure is needed. It won't work with re-running make only. Best regards, Karli On 03/19/2013 04:59 PM, Nystrom, William D wrote: > Hi Karli, > > I will try this soon and report back when I have results. > > Thanks, > > Dave > > ________________________________________ > From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > Sent: Tuesday, March 19, 2013 3:58 PM > To: For users of the development version of PETSc > Subject: [petsc-dev] CMake-assisted CUDA builds ready > > Dear all, > > I just merged the CMake-based builds for CUDA-packages into 'next', > reducing compilation times considerably compared to the old legacy > builds. While the legacy builds print something like > 'libfast in <DIR>' > the new CMake-based builds print the usual percentage counters in front. > > Any feedback on the proper functionality (both positive and negative) > are appreciated. > > Thanks and best regards, > Karli >

1 0

Re: [petsc-dev] Add natural-to-global and global-to-natural operations for DM?
by Barry Smith 20 Mar '13

20 Mar '13

On Mar 20, 2013, at 9:44 AM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: > Hi Barry, > > We use the natural vector when dumping to an HDF5 file and during initialization. You should be using the PETSc HDF5 viewer for "dumping to an HDF5 file" with DMDA vectors, it will correctly handle the natural ordering business. You can use PetscViewerHDF5GetFileId() so that you can mix PETSc dumped vectors and "your own stuff" all stored in the same HDF5 file. For unstructured you would again replace the VecView() and VecLoad() operations in your DM vectors to use whatever HDF5 code you use for dumping them. Thus you would always simply use VecView() to store PETSc vectors (regardless of DM) and VecLoad() to load them. Barry > When we are writing out raw "PETSc"-formatted vectors, we of course don't need to do the mapping. I agree with your argument for not bringing GlobalToNatural down to the DM level. > > --Richard > > On 3/20/13 9:49 AM, Barry Smith wrote: >> Richard, >> >> Once you have the vector in the "natural order" what do you do with it? >> >> 1) visualize it? >> 2) store to disk? >> 3) send to one process so you can do something on it? >> 3) ??? >> >> Note that VecView() on DMDA vectors automatically manage the mapping to natural ordering when saving to disk so the user does not ever need to apply globaltonatural themselves. >> >> I would argue that the only "legitimate" use of DMDAGlobalToNatural/NaturalToGlobal() is for IO (or similarly transferring a DMDA vector between two MPI communicators of different sizes) so my inclination is to make DMDAGlobalToNatural() less public, not bring it down to the DM level. >> >> If you are using GlobalToNatural in your IO I would argue that better approach is to imbed the mapping inside the VecLoad and VecView for your DM unstructured then you do not need need a universal DMGlobalToNatural(); >> >> I do not object to a DMLocalToLocalBegin/End(), though local is not universal we do have the local concept at the DM level already and it will remain there. >> >> Barry >> >> >> On Mar 19, 2013, at 9:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: >> >>> Hi Barry, >>> >>> What we call the "natural" ordering in PFLOTRAN is what is referred to as the "application" ordering in PETSc parlance. In the structured grid case this "application" ordering is the natural ordering used by the DMDA routines like DMDANaturalToGlobalBegin()/End(), and in the unstructured case it is whatever ordering was used to assign cell IDs when the unstructured grid was created. Rather than having code for two cases, I would prefer to be able to just call DMNaturalToGlobalBegin()/End() for either case. I do realize, of course, that for the DMDA case there is always a default meaning for the "natural" ordering, whereas for the case of a general DM the notion of "natural" will be application dependent and will have to be specified by user code (which I'd like to do in this case by having a DMShellSetNaturalToGlobalVecScatter()). >>> >>> Obviously, there may be subtypes of DM for which no "natural to global" operation makes sense. What I'm saying is that I nonetheless would like to have a general DMNaturalToGlobalBegin()/End() that will do the appropriate thing if it makes sense for that DM and complain otherwise. I guess this is a question of what the PETSc philosophy is regarding such things. I note that there is at least one example of a current DMDA method that ought to just be a DM one: I don't see why we should have DMDALocalToLocalBegin()/End() and not just DMLocalToLocalBegin()/End(), and I'd like to go ahead and change this. But LocalToLocal makes sense for lots of DMs, and NaturalToGlobal may not. >>> >>> --Richard >>> >>> On 3/7/13 10:51 PM, Barry Smith wrote: >>>> On Mar 7, 2013, at 9:46 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: >>>> >>>>> Continuing on my quest to be able to wrap all of the unstructured grid operations in PFLOTRAN inside a DM: Would it be OK to add DMGlobalToNaturalBegin()/End() and DMNatualToGlobalBegin()/End()? These are currently DMDA routines, not DM ones. We do something that we call natural-to-global and global-to-natural operations with our unstructured grid cases in PFLOTRAN (though I'm not sure if "natural" is quite the thing to call it... I always think of that in terms of a structured grid layout). I would like to just call DMGlobalToNaturalBegin()/End(), etc., on our DM, whether it is a DMDA or a DMShell. >>>>> >>>>> I had already mentioned that I plan to add DM interface routines for local-to-local operations. I am thinking that global-to-natural, etc., also ought to be added, though I'm not sure if the concept of "natural" ordering necessarily makes sense in some cases. >>>> What does natural mean for you on anything but a DA in what you do with pflotran? Once we all understand than we can come up with ideas on how that fits with DM. >>>> >>>> Barry >>>> >>>>> --Richard >>>>> >>>>> -- >>>>> Richard Tran Mills, Ph.D. >>>>> Computational Earth Scientist | Joint Assistant Professor >>>>> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >>>>> Oak Ridge National Laboratory | University of Tennessee, Knoxville >>>>> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >>>>> >>> >>> -- >>> Richard Tran Mills, Ph.D. >>> Computational Earth Scientist | Joint Assistant Professor >>> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >>> Oak Ridge National Laboratory | University of Tennessee, Knoxville >>> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >>> > > > -- > Richard Tran Mills, Ph.D. > Computational Earth Scientist | Joint Assistant Professor > Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences > Oak Ridge National Laboratory | University of Tennessee, Knoxville > E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >

1 0

Re: [petsc-dev] Reminder planning release soon
by Paul Mullowney 20 Mar '13

20 Mar '13

Is my aijcusparse-icc branch going to get merged into next? Do I need to do this? Do I have permissions? Thanks, -Paul > This is a reminder that we are planning a release soon thus one should start testing and moving completed work over to the git next branch for nightly testing and then on to master. > > Barry >

1 0

Re: [petsc-dev] Add natural-to-global and global-to-natural operations for DM?
by Barry Smith 20 Mar '13

20 Mar '13

On Mar 20, 2013, at 9:32 AM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: > On 3/19/13 11:38 PM, Jed Brown wrote: >> On Tue, Mar 19, 2013 at 9:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: >> [...] >> Obviously, there may be subtypes of DM for which no "natural to global" operation makes sense. >> >> At the type level, adding something to base DM is an assertion that it makes sense with all DMs. Even a local space does not strictly make sense in DM (some problems are dense, in which case the "local" space would be everything, which is likely a poor representation for the operator). > Yes, there is that implicit assumption when adding something to the base functionality; that said, there are cases scattered throughout PETSc where there are "base" operations that are not supported by all of the subclasses, so I'm not sure how this judgement call is made. > > I also agree that working in the "local" neighborhood is not a sensible thing to do for all DMs, but there still is some notion of "local", even if you wouldn't want to use it. I certainly think that since there is support for GlobalToLocal and LocalToGlobal operations at the DM base level, that for consistency there should also be LocalToLocal support, rather than embedding that functionality at the sub-class level. >> >> So I would be reluctant to add the Natural concept since it does not make sense with all DMs. What do you do with the natural vector coming out of here? Why is it easier to implement dispatch in DM rather than in your code? > We only use the natural ordering for things like doing I/O Ok, then embed the transformation into the VecView and VecLoad for the Vecs associated with the DM (as they are automatically for DMDA.) Note you should NOT be calling DMDAGlobalToNatural() in your IO for DMDA, it should be done automatically and can be set up similarly for your new DM (just add DMCreateGlobalVector_MyGlobal) for your DM and have it switch the View and Load methods for the vectors. > and for setting up source/sink terms or boundary conditions on nodesets/sidesets. You should be transferring any information about source/sink or boundary conditions on the "natural" mesh to the new mesh when the new mesh is created and not needing to do these operations in the original "natural" mesh. It is odd and adds unneeded complexity to your numerics to do some portions of the function evaluation on the final mesh organization and some on the "natural" plus not scalable because presumably your "natural" mesh is not good for parallelism or you would just always use it. > I have no actual need to do this at the DM level--I just like the idea of doing it this way for any DM type since we use DMDA routines in the structured case. We can certainly continue to do it in the PFLOTRAN code without a need for DM routine for it. > > I *do* have a "need" to do LocalToLocal operations on any DM type, however, as this isn't something that just happens during initialization and output. As I said, it is fine to move this down to DM. Barry > > --Richard

1 0

Re: [petsc-dev] Add natural-to-global and global-to-natural operations for DM?
by Richard Tran Mills 20 Mar '13

20 Mar '13

Hi Barry, We use the natural vector when dumping to an HDF5 file and during initialization. When we are writing out raw "PETSc"-formatted vectors, we of course don't need to do the mapping. I agree with your argument for not bringing GlobalToNatural down to the DM level. --Richard On 3/20/13 9:49 AM, Barry Smith wrote: > Richard, > > Once you have the vector in the "natural order" what do you do with it? > > 1) visualize it? > 2) store to disk? > 3) send to one process so you can do something on it? > 3) ??? > > Note that VecView() on DMDA vectors automatically manage the mapping to natural ordering when saving to disk so the user does not ever need to apply globaltonatural themselves. > > I would argue that the only "legitimate" use of DMDAGlobalToNatural/NaturalToGlobal() is for IO (or similarly transferring a DMDA vector between two MPI communicators of different sizes) so my inclination is to make DMDAGlobalToNatural() less public, not bring it down to the DM level. > > If you are using GlobalToNatural in your IO I would argue that better approach is to imbed the mapping inside the VecLoad and VecView for your DM unstructured then you do not need need a universal DMGlobalToNatural(); > > I do not object to a DMLocalToLocalBegin/End(), though local is not universal we do have the local concept at the DM level already and it will remain there. > > Barry > > > > On Mar 19, 2013, at 9:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: > >> Hi Barry, >> >> What we call the "natural" ordering in PFLOTRAN is what is referred to as the "application" ordering in PETSc parlance. In the structured grid case this "application" ordering is the natural ordering used by the DMDA routines like DMDANaturalToGlobalBegin()/End(), and in the unstructured case it is whatever ordering was used to assign cell IDs when the unstructured grid was created. Rather than having code for two cases, I would prefer to be able to just call DMNaturalToGlobalBegin()/End() for either case. I do realize, of course, that for the DMDA case there is always a default meaning for the "natural" ordering, whereas for the case of a general DM the notion of "natural" will be application dependent and will have to be specified by user code (which I'd like to do in this case by having a DMShellSetNaturalToGlobalVecScatter()). >> >> Obviously, there may be subtypes of DM for which no "natural to global" operation makes sense. What I'm saying is that I nonetheless would like to have a general DMNaturalToGlobalBegin()/End() that will do the appropriate thing if it makes sense for that DM and complain otherwise. I guess this is a question of what the PETSc philosophy is regarding such things. I note that there is at least one example of a current DMDA method that ought to just be a DM one: I don't see why we should have DMDALocalToLocalBegin()/End() and not just DMLocalToLocalBegin()/End(), and I'd like to go ahead and change this. But LocalToLocal makes sense for lots of DMs, and NaturalToGlobal may not. >> >> --Richard >> >> On 3/7/13 10:51 PM, Barry Smith wrote: >>> On Mar 7, 2013, at 9:46 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: >>> >>>> Continuing on my quest to be able to wrap all of the unstructured grid operations in PFLOTRAN inside a DM: Would it be OK to add DMGlobalToNaturalBegin()/End() and DMNatualToGlobalBegin()/End()? These are currently DMDA routines, not DM ones. We do something that we call natural-to-global and global-to-natural operations with our unstructured grid cases in PFLOTRAN (though I'm not sure if "natural" is quite the thing to call it... I always think of that in terms of a structured grid layout). I would like to just call DMGlobalToNaturalBegin()/End(), etc., on our DM, whether it is a DMDA or a DMShell. >>>> >>>> I had already mentioned that I plan to add DM interface routines for local-to-local operations. I am thinking that global-to-natural, etc., also ought to be added, though I'm not sure if the concept of "natural" ordering necessarily makes sense in some cases. >>> What does natural mean for you on anything but a DA in what you do with pflotran? Once we all understand than we can come up with ideas on how that fits with DM. >>> >>> Barry >>> >>>> --Richard >>>> >>>> -- >>>> Richard Tran Mills, Ph.D. >>>> Computational Earth Scientist | Joint Assistant Professor >>>> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >>>> Oak Ridge National Laboratory | University of Tennessee, Knoxville >>>> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >>>> >> >> -- >> Richard Tran Mills, Ph.D. >> Computational Earth Scientist | Joint Assistant Professor >> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences >> Oak Ridge National Laboratory | University of Tennessee, Knoxville >> E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills >> -- Richard Tran Mills, Ph.D. Computational Earth Scientist | Joint Assistant Professor Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences Oak Ridge National Laboratory | University of Tennessee, Knoxville E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills

1 0

Re: [petsc-dev] Add natural-to-global and global-to-natural operations for DM?
by Richard Tran Mills 20 Mar '13

20 Mar '13

On 3/19/13 11:38 PM, Jed Brown wrote: > On Tue, Mar 19, 2013 at 9:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu > <mailto:[email protected]>> wrote: > > [...] > Obviously, there may be subtypes of DM for which no "natural to > global" operation makes sense. > > > At the type level, adding something to base DM is an assertion that it > makes sense with all DMs. Even a local space does not strictly make > sense in DM (some problems are dense, in which case the "local" space > would be everything, which is likely a poor representation for the > operator). Yes, there is that implicit assumption when adding something to the base functionality; that said, there are cases scattered throughout PETSc where there are "base" operations that are not supported by all of the subclasses, so I'm not sure how this judgement call is made. I also agree that working in the "local" neighborhood is not a sensible thing to do for all DMs, but there still is some notion of "local", even if you wouldn't want to use it. I certainly think that since there is support for GlobalToLocal and LocalToGlobal operations at the DM base level, that for consistency there should also be LocalToLocal support, rather than embedding that functionality at the sub-class level. > > So I would be reluctant to add the Natural concept since it does not > make sense with all DMs. What do you do with the natural vector coming > out of here? Why is it easier to implement dispatch in DM rather than in > your code? We only use the natural ordering for things like doing I/O and for setting up source/sink terms or boundary conditions on nodesets/sidesets. I have no actual need to do this at the DM level--I just like the idea of doing it this way for any DM type since we use DMDA routines in the structured case. We can certainly continue to do it in the PFLOTRAN code without a need for DM routine for it. I *do* have a "need" to do LocalToLocal operations on any DM type, however, as this isn't something that just happens during initialization and output. --Richard

1 0

Re: [petsc-dev] I question the existence of PetscErrorCode (*createlocaltoglobalmapping)(DM); PetscErrorCode (*createlocaltoglobalmappingblock)(DM);
by Jed Brown 20 Mar '13

20 Mar '13

done On Wed, Mar 20, 2013 at 9:18 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 20, 2013, at 9:14 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > > On Wed, Mar 20, 2013 at 9:02 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > This is wrong and needs fixing, having one name for the public > interface and a different name in the function table. You need to change > the name in the function table to get() and > DMCreateLocalToGlobalMapping_Composite() and friends to use the name DMGet… > > > > That would imply that each DM* implementation would need to manage > caching, which is a bit of boilerplate, but perhaps okay in the interest of > consistency. Or do we start/reinforce a convention that some implementation > Get methods are called at most once because the outer part manages caching? > > No. Just change the name but leave everything else identical to the way > it is now. There is nothing wrong with the way it is implemented, just the > inconsistent naming. > > Barry > > > > > Having this inconsistent naming already wasted my time, and your time > responding to the email and everyone else's time in having to delete the > email. I'd fix it but git workflow is too hard so you need to fix it. > Consistency reduces complexity. > > > > I don't mind making the change, but here's the process to get a new > branch into 'next': > > > > $ git checkout -b name/dmgetlocaltoglobalmapping master > > change source, test, and commit > > $ git checkout next > > $ git merge name/dmgetlocaltoglobalmapping > > $ test > > $ git push origin next name/dmgetlocaltoglobalmapping > > > >

1 0