[petsc-users] Extra Variable in DMCircuit

[Florian Meier]

On 14.03.2014 20:59, Abhyankar, Shrirang G. wrote:
> 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)

Oh yes, Outlook does funny things (based on the variety of weird
formatted emails) :-)
Anyway, the style is visible in Thunderbird, but not in the plain text.
Maybe you could turn off HTML composition temporarily.

>>> 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"

I see, that is good!


>>> 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"

Yes

>>> 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."

No, not during the calculation, but there will be another kind of edges
where some vertices are connected in both directions and others only in
one direction.

I assume it does not make much sense to speculate about that now. There
is still a lot of work to do until everything will run reasonable on a
single core (e.g. I still use finite differences...). After that we will
see if and how it will be possible to parallelize it.

By the way: My mail address is wrong in the source code you sent me. It
is koalo not koala.

Thanks,
Florian



> 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
>