[petsc-users] Extra Variable in DMCircuit

[Abhyankar, Shrirang G.]

Arrgggh..Outlook!! I have no freakin idea how to resolve this. I'll have to sit with the IT help desk guys to figure it out. 
I made sure that the quoting levels were on and even changed to different font size with a different color before sending out that email!! Funnily, 
this email looks fine in Outlook Exchange. This is really retarded! 
Anyways, this was my reply (I am putting it in quotes now, hopefully Microsoft doesn't remove this)

>> Although, this solution seems to be very specific to
>> the equations. Does this approach still work when the equations get more
>> complex (e.g. handling multiple variables like PRODUCT(1+t*(a-1)) or
>> SUM(R*q*(1-f)) )?


Shri: "Managing custom needs is difficult to maintain hence what I'm planning to do is to provide a way for the user to define a own custom MPI_Op that can be called
by DMLocalToGlobalXXX/DMGlobalToLocalXXX. So eventually you'll have to write the MPI_Op and we'll provide hooks to attach it to the DM"

>> The additional equation is the multiplication of the reliability over a
>> specific path in the network (a rather arbitrary, but small subset of
>> the links (e.g. 55 links for a problem with 10000 links)) minus a
>> constant predefined value.
>> This gives me the possibility to convert the formerly constant packet
>> generation (g_i) into a variable.
>> 

Shri: "I see..so it is like an equality constraint on a subset of links, not all the links. Presumably these links form a subnetwork that
may get assigned to one processor/set of neighboring processors"

>> Good idea, but unfortunately it is not always guaranteed that the edge
>> is bidirectional for the extended formulation of the problem.
>> 

Shri: "Are you saying that the directionality could change during the calculation?
In your example, the INTERFERING edges are bidirectional
while the INFLOWING links are unidirectional. By setting up the appropriate relations in the
data attached with the edges , you can manage the equations for the
edges/vertices. If there is some specific case that cannot be handled then we can take a look at it."

>> What
>> exactly is the problem when the two unidirectional edges are assigned to
>> different processes?
>> 

Shri: "I don't quite remember it right now but I recall seeing weird partitions and incorrect ghost exchanges. I'll have to run it once again
to produce specific details."

On Mar 14, 2014, at 2:26 PM, Jed Brown wrote:

> Your email quoting style is really hard to read.  What part is you and
> what part is supposed to be cited?  (Microsoft is at-fault for this
> breakage, but we need a work-around.)
> 
> http://lists.mcs.anl.gov/pipermail/petsc-users/2014-March/020931.html
> 
> "Abhyankar, Shrirang G." <abhyshr at mcs.anl.gov> writes:
> 
>> -----Original Message-----
>> From: Florian Meier <florian.meier at koalo.de<mailto:florian.meier at koalo.de>>
>> Date: Fri, 14 Mar 2014 19:34:23 +0100
>> To: Shri <abhyshr at mcs.anl.gov<mailto:abhyshr at mcs.anl.gov>>
>> Cc: petsc-users list <petsc-users at mcs.anl.gov<mailto:petsc-users at mcs.anl.gov>>
>> Subject: Re: Extra Variable in DMCircuit
>> 
>> On 03/14/2014 06:24 PM, Abhyankar, Shrirang G. wrote:
>> 
>> 
>> That sounds great! Although, this solution seems to be very specific to
>> the equations. Does this approach still work when the equations get more
>> complex (e.g. handling multiple variables like PRODUCT(1+t*(a-1)) or
>> SUM(R*q*(1-f)) )?
>> 
>> Managing custom needs is difficult to maintain hence what I'm planning to do is to provide a way for the user to define a own custom MPI_Op that can be called
>> by DMLocalToGlobalXXX/DMGlobalToLocalXXX. So eventually you'll have to write the MPI_Op and we'll provide hooks to attach it to the DM.
>> 
>> 
>> Now I would like to add a single global variable (and a single equation)
>> to the equation system. Is there an elegant way to do this with DMCircuit?
>> Is this akin to a "Ground" node for circuits? Is the variable value
>> constant?
>> 
>> Maybe...
>> The additional equation is the multiplication of the reliability over a
>> specific path in the network (a rather arbitrary, but small subset of
>> the links (e.g. 55 links for a problem with 10000 links)) minus a
>> constant predefined value.
>> This gives me the possibility to convert the formerly constant packet
>> generation (g_i) into a variable.
>> 
>> I see..so it is like an equality constraint on a subset of links, not all the links. Presumably these links form a subnetwork that
>> may get assigned to one processor/set of neighboring processors.
>> 
>> 
>> When adding an additional vertex it works quite good. We will see how it
>> works out when running in parallel.
>> 
>> After working on your example I realized that specifying a bidirectional
>> edge as two unidirectional edges in the data may cause problems for the
>> partitioner. I observed that
>> the two undirectional edges may be assigned to different processors
>> although they are connected to the same vertices. This may be a problem
>> when communicating ghost
>> values. Hence, I've modified the data format in the attached links1.txt
>> file to only specify edges via their nodal connectivity and then to
>> specify the type information.
>> I've reworked your source code also accordingly and it gives the same
>> answer as your original code. It gives a wrong answer for parallel runs
>> because of the incorrect
>> ghost value exchanges. Once we have the ADD_PROD insertmode, this code
>> should work fine in parallel too. I think that going forward you should
>> use a similar data format.
>> 
>> Good idea, but unfortunately it is not always guaranteed that the edge
>> is bidirectional for the extended formulation of the problem.
>> 
>> Are you saying that the directionality could change during the calculation?
>> In your example, the INTERFERING edges are bidirectional
>> while the INFLOWING links are unidirectional. By setting up the appropriate relations in the
>> data attached with the edges , you can manage the equations for the
>> edges/vertices. If there is some specific case that cannot be handled then we can take a look at it.
>> 
>> What
>> exactly is the problem when the two unidirectional edges are assigned to
>> different processes?
>> 
>> I don't quite remember it right now but I recall seeing weird partitions and incorrect ghost exchanges. I'll have to run it once again
>> to produce specific details.
>> 
>> Shri
>> 
>> A hackish solution might be to add an additional imaginary vertex that
>> is excluded from all other calculations, but that does not seem to be
>> the right way to do it.
>> Greetings,
>> Florian