Variable Order in Input File

[Shane Keniley]

I'm seeing some strange behavior using the DriftDiffusionAction that was pushed last week. There's no issue with the action itself - what I'm seeing is varying convergence performance depending on where I place the action in the input file. 

I believe I've tracked the actual problem to the variable initialization order. When I comment out the addVariable portion of the action and add everything manually (but still add the Kernels and AuxKernels through the action) everything works perfectly fine and I get the same solution times as I do without the action. If I let the variables be added via the action, convergence becomes noticeably worse - the problem gets stuck around 10 ns timesteps instead of 100 ns timesteps so it's a very significant difference. I think the problematic sections are specifically the two scalar variables I've been using as the surface charge values; without the action, if I add them first in the [Variables] block there's no trouble, but if I add them last then I run into convergence issues.

Interestingly, when I move the action so that it's placed after the Variables block in the input file, everything works fine! So I think it's pretty clear that the action isn't doing anything wrong; I just get problems when the action's add_variables block is accessed before the [Variables] block in the input file. 

Is there any reason why the order in which I add variables in the input file affects convergence so much?  In case it matters, I'm running with PJFNK and an lu preconditioner. My best guess is that the actual matrix that the problem is solving is constructed in the order the input file is written, and it might just be easier for PETSc to handle one matrix over another even if the only difference between the two is variable placement.  

If that's the case, is there any general rule we should be following to prevent this in the future? So far all I can say for certain is that it's better to add scalar variables to a problem first. I have no idea why. 

[Alexander Lindsay]

On Thu, Apr 23, 2020 at 1:55 PM Shane Keniley <keni...@illinois.edu> wrote:

I'm seeing some strange behavior using the DriftDiffusionAction that was pushed last week. There's no issue with the action itself - what I'm seeing is varying convergence performance depending on where I place the action in the input file. 

I believe I've tracked the actual problem to the variable initialization order. When I comment out the addVariable portion of the action and add everything manually (but still add the Kernels and AuxKernels through the action) everything works perfectly fine and I get the same solution times as I do without the action. If I let the variables be added via the action, convergence becomes noticeably worse - the problem gets stuck around 10 ns timesteps instead of 100 ns timesteps so it's a very significant difference. I think the problematic sections are specifically the two scalar variables I've been using as the surface charge values; without the action, if I add them first in the [Variables] block there's no trouble, but if I add them last then I run into convergence issues.

Interestingly, when I move the action so that it's placed after the Variables block in the input file, everything works fine! So I think it's pretty clear that the action isn't doing anything wrong; I just get problems when the action's add_variables block is accessed before the [Variables] block in the input file. 

Is there any reason why the order in which I add variables in the input file affects convergence so much?  In case it matters, I'm running with PJFNK and an lu preconditioner. My best guess is that the actual matrix that the problem is solving is constructed in the order the input file is written, and it might just be easier for PETSc to handle one matrix over another even if the only difference between the two is variable placement.  

Your guess is accurate. The structure of the matrix absolutely plays a roll in the quality of the solve.

If that's the case, is there any general rule we should be following to prevent this in the future? So far all I can say for certain is that it's better to add scalar variables to a problem first. I have no idea why. 

I'm curious whether this statement is true in a generic sense or only true for this set of physics.

For insight about how to order variables, I would post to the moose mailing list and see whether Fande Kong has a good answer. Or you could even post to the PETSc users list.

--
You received this message because you are subscribed to the Google Groups "zapdos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zapdos-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zapdos-users/0232b0e5-b44c-4634-b226-9f9bc7514749%40googlegroups.com.