[FLASH-USERS] Question about resistivity varying in space

Tue Nov 14 12:10:21 EST 2023

Unfortunately  the MagneticResistivity interface doesn’t pass any information about the grid, blockID or otherwise, only the UNK array at a single cell.

Since the cell coordinates vary linearly I think the AMR prolongation should take care of the case of mesh refinement.
*********************************************
Adam Reyes

Code Group Leader, Flash Center for Computational Science  
Research Scientist, Dept. of Physics and Astronomy
University of Rochester
River Campus: Bausch and Lomb Hall, 369  
500 Wilson Blvd. PO Box 270171, Rochester, NY 14627
Email adam.reyes at rochester.edu
Web https://flash.rochester.edu
 (he / him / his)

*********************************************

> On Nov 14, 2023, at 6:01 PM, John Zuhone <jzuhone at gmail.com> wrote:
> 
> The solution to put the coordinates in variables is overkill, using up memory, and doesn’t work if you only do it in Simulation_initBlock and then the mesh refines later. 
> 
> You need to use Grid_getCellCoords, which has a public interface and can be called from the MagneticResistivity unit:
> 
> use Grid_interface, ONLY: Grid_getCellCoords, Grid_getBlkIndexLimits
> 
> #include "Flash.h"
> 
> logical :: gcell = .true. ! True if you need the guardcells, false if not
> real :: size(3)
> real, dimension(:), allocatable :: xc, yc, zc
> integer, dimension(LOW:HIGH,MDIM) :: blkLimits,blkLimitsGC
> 
> ! for a given blockId: 
> 
> call Grid_getBlkIndexLimits(blockID,blkLimits,blkLimitsGC)
> 
> if (gcell) then
>   size(1) = blkLimitsGC(HIGH,IAXIS) - blkLimitsGC(LOW,IAXIS) + 1
>   size(2) = blkLimitsGC(HIGH,JAXIS) - blkLimitsGC(LOW,JAXIS) + 1
>   size(3) = blkLimitsGC(HIGH,KAXIS) - blkLimitsGC(LOW,KAXIS) + 1
> else
>   size(1) = blkLimits(HIGH,IAXIS) - blkLimits(LOW,IAXIS) + 1
>   size(2) = blkLimits(HIGH,JAXIS) - blkLimits(LOW,JAXIS) + 1
>   size(3) = blkLimits(HIGH,KAXIS) - blkLimits(LOW,KAXIS) + 1
> endif
> 
> call Grid_getCellCoords(KAXIS, blockId, CENTER, gcell, zc, size(3))
> call Grid_getCellCoords(JAXIS, blockId, CENTER, gcell, yc, size(2))
> call Grid_getCellCoords(IAXIS, blockId, CENTER, gcell, xc, size(1))
> 
> The xc, yc, zc now contain the cell coordinates for the block. 
> 
> 
>> On Nov 14, 2023, at 11:29 AM, Leland Ellison <lee at pacificfusion.energy> wrote:
>> 
>> Hi Ernesto,
>> 
>> To make a custom magnetic resistivity model that depends on spatial coordinates, I'd do this by customizing the MagneticResitivity_fullState.f90 file in your problem directory. Notice that the fullState version gets passed in the full vector of unknowns and not just the density and temperature. If you look carefully at e.g. diff_advanceMag, it's actually calling the fullState version by passing in the solnVec so this is the one you want to customize. Next, as you noticed, you don't typically have the spatial coordinates available in your solnVec, but it's quite straightforward to add them. For instance, you can add:
>> 
>> VARIABLE XCTR
>> VARIABLE YCTR
>> VARIABLE ZCTR 
>> 
>> in the Config file for your problem, and then in your Simulation_initBlock you can populate these mesh variables with cell centered coordinates, e.g.:
>> 
>> ! inside your i,j,k mesh loop after you've fetched the spatial coordinates
>> #ifdef XCTR_VAR
>>         solnData(XCTR_VAR, i,j,k) = xCoord(i)
>> #endif
>> 
>> Then these coordinates will be present in your solnVec for use inside of your customized MagneticResistivity_fullState routine. 
>> 
>> Hope this helps!
>> Lee
>> 
>> ________________
>> Leland Ellison PhD
>> 
>> 
>> On Tue, Nov 14, 2023 at 7:56 AM Ernesto Zurbriggen <ezurbriggen at unc.edu.ar <mailto:ezurbriggen at unc.edu.ar>> wrote:
>>> Hi all! 
>>> I'm carrying out some single fluid resistive MHD runs with constant resistivity using the /MagneticResistivity/MagneticResistivityMain/Constant unit. 
>>> Now I would like to implement a spatially dependent resistivity, but I'm not sure which is the easiest way without modifying different subroutines in different units.  
>>> 
>>> The optimal implementation would be to create a new unit that keeps the structure of the /MagneticResistivity/MagneticResistivityMain/Constant unit, 
>>> so I didn't have to change anything else in other units. But the problem with this idea is that the MagneticResistivity subroutine, 
>>> which calculates the resistivity, has no notion of spatial coordinates. And to provide this subroutine with the spatial coordinates doesn't seem obvious. 
>>> 
>>> Another possibility might be to save the resistivity in a scratchcenter variable, but in this case I couldn't take advantage of the structure of the /MagneticResistivity/MagneticResistivityMain/Constant unit. 
>>> 
>>> Any ideas or suggestions will be appreciated!
>>> 
>>> Thanks in advance! 
>>> 
>>> --
>>> PhD Ernesto Zurbriggen,
>>> Assistant researcher (CONICET)
>>> Email: ezurbriggen@ <mailto:ernesto.zurbriggen at craam.mackenzie.br>unc.edu.ar <http://unc.edu.ar/>
>>> IP phone: (+54) 351-535 3776 (int. 75601)
>>> 
>>> Instituto de Astronomía Teórica y Experimental (IATE-CONICET), 
>>> Francisco Laprida sth 922, X5000BGR, Córdoba, Argentina. 
>>> _______________________________________________
>>> flash-users mailing list
>>> flash-users at flash.rochester.edu <mailto:flash-users at flash.rochester.edu>
>>> 
>>> For list info, including unsubscribe:
>>> https://flash.rochester.edu/mailman/listinfo/flash-users
>> _______________________________________________
>> flash-users mailing list
>> flash-users at flash.rochester.edu
>> 
>> For list info, including unsubscribe:
>> https://flash.rochester.edu/mailman/listinfo/flash-users
> 
> _______________________________________________
> flash-users mailing list
> flash-users at flash.rochester.edu
> 
> For list info, including unsubscribe:
> https://flash.rochester.edu/mailman/listinfo/flash-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20231114/508f3da4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FLASH.jpg
Type: image/jpeg
Size: 23876 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20231114/508f3da4/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FLASH-pride-sml.png
Type: image/png
Size: 12732 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20231114/508f3da4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1391 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20231114/508f3da4/attachment-0001.p7s>