[FLASH-USERS] [EXT] Question about resistivity varying in space
Ernesto Zurbriggen
ezurbriggen at unc.edu.ar
Tue Nov 14 12:44:54 EST 2023
Thanks for all your answers!
>>Ah, you don’t have the blockID, I see now. That’s unfortunate.
Unfortunately that is the case.
I will look into the best way to get it!
On Tue, 14 Nov 2023 at 14:16, Reyes, Adam <adam.reyes at rochester.edu> wrote:
> Yes you can call Grid_getCellCoords from MagneticResistivity, but the
> MagneticResistivity subroutine itself has no way of knowing what cell index
> it’s being called on:
>
> interface MagneticResistivity
>
> subroutine MagneticResistivity(temp,dens,xn,magResist)
> real, intent(IN) :: temp, dens
> real, intent(IN), dimension(NSPECIES) :: xn
> real, intent(OUT) :: magResist
> end subroutine MagneticResistivity
>
> subroutine
> MagneticResistivity_fullState(solnVec,resPar,resPerp,resCross)
> real, intent(in) :: solnVec(NUNK_VARS)
> real, intent(out) :: resPar
> real, OPTIONAL, intent(out) :: resPerp
> real, OPTIONAL, intent(out) :: resCross
> end subroutine MagneticResistivity_fullState
>
>
> end interface
>
>
>
> *********************************************
> Adam Reyes
>
> [image: FLASH.jpg]
> 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)
> [image: FLASH-pride-sml.png]
>
> *********************************************
>
>
>
> On Nov 14, 2023, at 6:11 PM, John Zuhone <jzuhone at gmail.com> wrote:
>
> Adam,
>
> Sorry, a bit confused—is Grid_getCellCoords not part of the public
> interface? If so, you can call it from any other module, and get the cell
> coords that way.
>
> John
>
> On Nov 14, 2023, at 12:10 PM, Reyes, Adam <adam.reyes at rochester.edu>
> wrote:
>
> 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
>
> <FLASH.jpg>
> 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)
> <FLASH-pride-sml.png>
>
> *********************************************
>
>
>
> 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>
> 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@ <ernesto.zurbriggen at craam.mackenzie.br>unc.edu.ar
>> <https://urldefense.com/v3/__http://unc.edu.ar/__;!!CGUSO5OYRnA7CQ!Z9YCiJHBssBZJagnXHnn5cYcZHFWoOZxeO1cLs7SMJLnhDzEj7NCGwrIMuXz8CxNEQC2zOux3VHexkMG0gMC$>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
>>
>> 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
>
>
>
>
> _______________________________________________
> 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/3549a0a6/attachment.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/3549a0a6/attachment.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/3549a0a6/attachment.png>
More information about the flash-users
mailing list