From flash-users at flash.uchicago.edu  Thu May  1 20:27:07 2008
From: flash-users at flash.uchicago.edu (VIAGRA ® Official Site)
Date: Thu,  1 May 2008 20:27:07 -0500 (CDT)
Subject: [FLASH-USERS] [SPAM] Dear flash-users@flash.uchicago.edu May 84% 0FF
Message-ID: <20080502062712.24748.qmail@dsl85-104-12531.ttnet.net.tr>

An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080501/27d88897/attachment.html 

From hudson at mcs.anl.gov  Fri May  2 14:21:09 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Fri, 2 May 2008 14:21:09 -0500
Subject: [FLASH-USERS] VisIt - New submenus for flash data
Message-ID: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>


Concerning VisIt:

I don't remember if I already announced this, but, with the latest  
version of the flash plugin, the variable names for flash data appear  
under new, intervening submenus "mesh_blockandlevel" and  
"mesh_blockandproc".

I needed to add these when, to the original subsetting by blocks and  
refinement levels, I added subsetting by blocks and processor  
numbers.  I needed to define block-level and block-proc subsetting  
pairs, and, to make these both available, I needed the new submenus.

I also had added the visualization of the Morton curve, and that's  
subset-able both ways as well.


Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080502/49a0fbf3/attachment.html 

From dubey at flash.uchicago.edu  Fri May  2 15:12:36 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Fri, 2 May 2008 15:12:36 -0500
Subject: [FLASH-USERS] v cycle not converging
In-Reply-To: <4817616D.40508@astro.rug.nl>
References: <4817616D.40508@astro.rug.nl>
Message-ID: <5b942a610805021312n44e2b765hcec4dd815a3f2b26@mail.gmail.com>

Dear Latif,

If you are new to FLASH, I strongly recommend using FLASH 3 instead of FLASH
2.5
There is new multigrid algorithm in FLASH3 which is not only more
efficient,  but is
also better known by the current support team. You will get much better
support
in general.

Anshu

On Tue, Apr 29, 2008 at 12:57 PM, M.A. Latife <latife at astro.rug.nl> wrote:

> Hi,
> Dear All.
> First of all sorry for disturbing you again. i am not good in using flash
> .  i am asking  many questions hope you will not mind.
> i am simulating structure formation using FLASH 2.5 starting from redshift
> 25(Hydro+gravity+cosmology).
> when i put uniform density over whole domain. i get warning v-cycle not
> converging and results become worse. i am using periodic boundary conditions
>  both for hydro+ gravity.
> when i put over density at center (like Gaussian or Mexican hat) minimum
> density becomes small than it should be at particular redshift( like it
> becomes 1.0E-30 at redshift 15) although density should remain constant.
> My 2nd question is when is when using cosmology should i use comoving
> coordinates when initializing conditions in initial block. if yes then how?.
> i am taking  block centres and dividing them by scale factor in Initial
> block .
> any suggestions in this regard will be highly appreciated.
> Kind regards
> Latif
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080502/9470a3d1/attachment.html 

From seyit at astro.rug.nl  Tue May  6 10:40:10 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Tue, 06 May 2008 17:40:10 +0200
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
Message-ID: <48207BDA.102@astro.rug.nl>

Hi,

I don't know if anyone else has this, but VisIt 1.9.0 shows my 
pseudocolor plots completely black. Basically the color profile "Hot" is 
not working in my case. Even when I try to select "Hot" from colors, 
VisIt directly crashes. Whenever I change to a different color profile, 
then it works. Except that there are few random colored blocks showing 
here and there, also odd.

Btw, there is another thing unmentioned I think. Starting VisIt for 
FLASH now needs the command "-assume_format FLASH" instead of 
"-default_format FLASH". "-fallback_format FLASH" also works, but slower.

Greetz,
Seyit

ps: I don't see any difference between "mesh_blockandlevel" and 
"mesh_blockandproc" plots.

>
> Concerning VisIt:
>
> I don't remember if I already announced this, but, with the latest 
> version of the flash plugin, the variable names for flash data appear 
> under new, intervening submenus "mesh_blockandlevel" and 
> "mesh_blockandproc".
>
> I needed to add these when, to the original subsetting by blocks and 
> refinement levels, I added subsetting by blocks and processor numbers. 
>  I needed to define block-level and block-proc subsetting pairs, and, 
> to make these both available, I needed the new submenus.
>
> I also had added the visualization of the Morton curve, and that's 
> subset-able both ways as well.
>
>
> Randy.
>
>
>


From jfg at ucolick.org  Tue May  6 18:56:59 2008
From: jfg at ucolick.org (James Guillochon)
Date: Tue, 06 May 2008 16:56:59 -0700
Subject: [FLASH-USERS] Problem with Fidlr3.0
Message-ID: <4820F04B.3070601@ucolick.org>

Hi,

I am trying to use the loaddata routine in fidlr3, and I get the 
following error message when I try to load data sets that are above 
~50mb per variable in size:

% Array dimensions must be greater than 0.
% Execution halted at: READ_AMR          409 
/FLASH3.0/tools/fidlr3.0/read_amr.pro
%                      LOADDATA           56 
/FLASH3.0/tools/fidlr3.0/loaddata.pro

The segment of code it refers to is the following:
    404   ;***********coordinates**************
    405   dataset = H5D_OPEN(file_identifier, "coordinates")
    406   dataspace = H5D_GET_SPACE(dataset)
    407   H5S_SELECT_HYPERSLAB, dataspace, start_2d, count_2d, 
STRIDE=stride_2d, /RESET
    408   memspace = H5S_CREATE_SIMPLE(count_2d)
    409   coord = H5D_READ(dataset, FILE_SPACE=dataspace, 
MEMORY_SPACE=memspace)
    410   H5D_CLOSE, dataset
    411   H5S_CLOSE, memspace
    412   H5S_CLOSE, dataspace

I have checked and the dataset, dataspace, and memspace variables have 
reasonable values. This bug does not occur if the dump file I am reading 
from is small enough in size. I am using IDL 7.0, have HDF5 1.8.0 
installed, and FLASH 3.0. I have tried downgrading to HDF5 1.6.7 and 
also tried IDL 6.3 on another machine but that didn't solve the problem. 
Any ideas guys?

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org

From josef.stoeckl at uibk.ac.at  Wed May  7 07:04:33 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 07 May 2008 14:04:33 +0200
Subject: [FLASH-USERS] Unsupported boundary condititions
Message-ID: <48219AD1.4040309@uibk.ac.at>

Hi,

I'm trying to set up a problem with "outflow" boundary conditions, but 
when I choose this BC type I always get the following message in my log:
gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for the 
WORK array

Looking inside that file seems to suggest that at the moment only a few 
boundary conditions are implemented and not all, which the Flash 3 
Manual lists. Is there some development version of the Grid code 
available that handles outflow conditions?

Thanks in advance and best regards to all,

Josef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/5f050868/attachment.vcf 

From gbp at phys.soton.ac.uk  Wed May  7 07:13:34 2008
From: gbp at phys.soton.ac.uk (Georgi Pavlovski)
Date: Wed, 07 May 2008 13:13:34 +0100
Subject: [FLASH-USERS] Problem with Fidlr3.0
In-Reply-To: <4820F04B.3070601@ucolick.org>
References: <4820F04B.3070601@ucolick.org>
Message-ID: <48219CEE.6020508@phys.soton.ac.uk>

Hi,

it might not be something you are willing to do, but what about using 
fildr2, which uses c library bindings for reading flash hdf5 into IDL? 
Otherwise, I would suggest using pytables or hlhdf and python to do data 
analysis.

- Georgi

James Guillochon wrote:
> Hi,
> 
> I am trying to use the loaddata routine in fidlr3, and I get the 
> following error message when I try to load data sets that are above 
> ~50mb per variable in size:
> 
> % Array dimensions must be greater than 0.
> % Execution halted at: READ_AMR          409 
> /FLASH3.0/tools/fidlr3.0/read_amr.pro
> %                      LOADDATA           56 
> /FLASH3.0/tools/fidlr3.0/loaddata.pro
> 
> The segment of code it refers to is the following:
>    404   ;***********coordinates**************
>    405   dataset = H5D_OPEN(file_identifier, "coordinates")
>    406   dataspace = H5D_GET_SPACE(dataset)
>    407   H5S_SELECT_HYPERSLAB, dataspace, start_2d, count_2d, 
> STRIDE=stride_2d, /RESET
>    408   memspace = H5S_CREATE_SIMPLE(count_2d)
>    409   coord = H5D_READ(dataset, FILE_SPACE=dataspace, 
> MEMORY_SPACE=memspace)
>    410   H5D_CLOSE, dataset
>    411   H5S_CLOSE, memspace
>    412   H5S_CLOSE, dataspace
> 
> I have checked and the dataset, dataspace, and memspace variables have 
> reasonable values. This bug does not occur if the dump file I am reading 
> from is small enough in size. I am using IDL 7.0, have HDF5 1.8.0 
> installed, and FLASH 3.0. I have tried downgrading to HDF5 1.6.7 and 
> also tried IDL 6.3 on another machine but that didn't solve the problem. 
> Any ideas guys?
> 

-- 
===================================================================
   Dr Georgi B. Pavlovski        School of Physics and Astronomy
   Tel: +44-(0)-23-8059-2089     University of Southampton
   Fax: +44-(0)-23-8059-3910     Southampton SO17 1BJ, U.K.
   Email: gbp at phys.soton.ac.uk   Web: www.astro.soton.ac.uk/~gbp
===================================================================



From dubey at flash.uchicago.edu  Wed May  7 08:06:41 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Wed, 7 May 2008 08:06:41 -0500
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <48219AD1.4040309@uibk.ac.at>
References: <48219AD1.4040309@uibk.ac.at>
Message-ID: <5b942a610805070606r691177d2obb7203258e53bed0@mail.gmail.com>

It appears that you are using the multigrid solver for gravity in your
simulation.
Self gravity in FLASH does not support outflow boundary conditions, most of
the
other solvers do. From the setups included with the distribution you can
check out
"Sod" and "Sedov", they both use outflow boundary conditions.

Anshu

On Wed, May 7, 2008 at 7:04 AM, Josef St?ckl <josef.stoeckl at uibk.ac.at>
wrote:

> Hi,
>
> I'm trying to set up a problem with "outflow" boundary conditions, but
> when I choose this BC type I always get the following message in my log:
> gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for the
> WORK array
>
> Looking inside that file seems to suggest that at the moment only a few
> boundary conditions are implemented and not all, which the Flash 3 Manual
> lists. Is there some development version of the Grid code available that
> handles outflow conditions?
>
> Thanks in advance and best regards to all,
>
> Josef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/8cf588f6/attachment.html 

From zuhone at flash.uchicago.edu  Wed May  7 08:11:48 2008
From: zuhone at flash.uchicago.edu (John ZuHone)
Date: Wed, 7 May 2008 09:11:48 -0400
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <48219AD1.4040309@uibk.ac.at>
References: <48219AD1.4040309@uibk.ac.at>
Message-ID: <278BE598-123B-46D5-954B-B33EDF2D8A30@flash.uchicago.edu>

Josef,

Following up on Anshu's recommendation, if you are using the multigrid  
solver the boundary condition you probably want to use is  
"isolated" (I'm guessing at what kind of problem you're trying to run,  
if you could specify that information that would also be helpful).  
This is what you need to set the "grav_boundary_type" parameter to in  
your flash.par. Other parameters, "xl_boundary", "xr_boundary", etc,  
should be set to outflow.

Best,

John

For hydrodynamics and/or particles, the bou
On May 7, 2008, at 8:04 AM, Josef St?ckl wrote:

> Hi,
>
> I'm trying to set up a problem with "outflow" boundary conditions,  
> but when I choose this BC type I always get the following message in  
> my log:
> gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for  
> the WORK array
>
> Looking inside that file seems to suggest that at the moment only a  
> few boundary conditions are implemented and not all, which the Flash  
> 3 Manual lists. Is there some development version of the Grid code  
> available that handles outflow conditions?
>
> Thanks in advance and best regards to all,
>
> Josef
> <josef_stoeckl.vcf>


From josef.stoeckl at uibk.ac.at  Wed May  7 08:19:40 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 07 May 2008 15:19:40 +0200
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <5b942a610805070606r691177d2obb7203258e53bed0@mail.gmail.com>
References: <48219AD1.4040309@uibk.ac.at>
	<5b942a610805070606r691177d2obb7203258e53bed0@mail.gmail.com>
Message-ID: <4821AC6C.3030403@uibk.ac.at>

Hi Anshu,

Yes, I'm indeed using the Multigrid solver. I didn't find any mention of 
this solver not working with "outflow", but I'll have to check again. I 
wonder though, isn't "grav_boundary_type" the boundary condition used 
for the self gravity? Because I had set that to "periodic" for my 
initial tests.

Thanks and best regards,
Josef


Anshu Dubey wrote:
> It appears that you are using the multigrid solver for gravity in your 
> simulation.
> Self gravity in FLASH does not support outflow boundary conditions, 
> most of the
> other solvers do. From the setups included with the distribution you 
> can check out
> "Sod" and "Sedov", they both use outflow boundary conditions.
>
> Anshu
>
> On Wed, May 7, 2008 at 7:04 AM, Josef St?ckl <josef.stoeckl at uibk.ac.at 
> <mailto:josef.stoeckl at uibk.ac.at>> wrote:
>
>     Hi,
>
>     I'm trying to set up a problem with "outflow" boundary conditions,
>     but when I choose this BC type I always get the following message
>     in my log:
>     gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for
>     the WORK array
>
>     Looking inside that file seems to suggest that at the moment only
>     a few boundary conditions are implemented and not all, which the
>     Flash 3 Manual lists. Is there some development version of the
>     Grid code available that handles outflow conditions?
>
>     Thanks in advance and best regards to all,
>
>     Josef
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/0a19abeb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/0a19abeb/attachment-0001.vcf 

From josef.stoeckl at uibk.ac.at  Wed May  7 08:22:24 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 07 May 2008 15:22:24 +0200
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <278BE598-123B-46D5-954B-B33EDF2D8A30@flash.uchicago.edu>
References: <48219AD1.4040309@uibk.ac.at>
	<278BE598-123B-46D5-954B-B33EDF2D8A30@flash.uchicago.edu>
Message-ID: <4821AD10.8090509@uibk.ac.at>

Hi John,

Actually I did have grav_boundary_type set to "periodic" in my tries, 
but it doesn't seem like it changed anything.

The problem I'm trying to set up is a cosmological cluster simulation, 
where it is usually best to have "in/outflow" boundaries set (depending 
on the code) to prevent some unwanted effects in the hydrodynamics and 
particles.

Thanks and best regards,
Josef

John ZuHone wrote:
> Josef,
>
> Following up on Anshu's recommendation, if you are using the multigrid 
> solver the boundary condition you probably want to use is "isolated" 
> (I'm guessing at what kind of problem you're trying to run, if you 
> could specify that information that would also be helpful). This is 
> what you need to set the "grav_boundary_type" parameter to in your 
> flash.par. Other parameters, "xl_boundary", "xr_boundary", etc, should 
> be set to outflow.
>
> Best,
>
> John
>
> For hydrodynamics and/or particles, the bou
> On May 7, 2008, at 8:04 AM, Josef St?ckl wrote:
>
>> Hi,
>>
>> I'm trying to set up a problem with "outflow" boundary conditions, 
>> but when I choose this BC type I always get the following message in 
>> my log:
>> gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for 
>> the WORK array
>>
>> Looking inside that file seems to suggest that at the moment only a 
>> few boundary conditions are implemented and not all, which the Flash 
>> 3 Manual lists. Is there some development version of the Grid code 
>> available that handles outflow conditions?
>>
>> Thanks in advance and best regards to all,
>>
>> Josef
>> <josef_stoeckl.vcf>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/f1079325/attachment.vcf 

From zuhone at flash.uchicago.edu  Wed May  7 08:31:45 2008
From: zuhone at flash.uchicago.edu (John ZuHone)
Date: Wed, 7 May 2008 09:31:45 -0400
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <4821AD10.8090509@uibk.ac.at>
References: <48219AD1.4040309@uibk.ac.at>
	<278BE598-123B-46D5-954B-B33EDF2D8A30@flash.uchicago.edu>
	<4821AD10.8090509@uibk.ac.at>
Message-ID: <41D85857-5DB3-4A27-827A-6AB2E11C649F@flash.uchicago.edu>

Hi Josef,

Sorry... want to make sure I understand precisely what you're doing....

Is this a cosmological box simulation in which clusters form, and  
which you're also incorporating cosmological expansion? Or is this a  
simulation of an isolated cluster? In the latter case you not only  
want multigrid and "grav_boundary_type" set to "isolated", but you  
also want to make sure that you're including the unit Grid/GridSolvers/ 
IsoBndMultipole.

If this is still not helpful, if you could send along your flash.par,  
and the files setup_call and setup_units in your object directory,  
that might provide more information.

Best,

John Z

On May 7, 2008, at 9:22 AM, Josef St?ckl wrote:

> Hi John,
>
> Actually I did have grav_boundary_type set to "periodic" in my  
> tries, but it doesn't seem like it changed anything.
>
> The problem I'm trying to set up is a cosmological cluster  
> simulation, where it is usually best to have "in/outflow" boundaries  
> set (depending on the code) to prevent some unwanted effects in the  
> hydrodynamics and particles.
>
> Thanks and best regards,
> Josef
>
> John ZuHone wrote:
>> Josef,
>>
>> Following up on Anshu's recommendation, if you are using the  
>> multigrid solver the boundary condition you probably want to use is  
>> "isolated" (I'm guessing at what kind of problem you're trying to  
>> run, if you could specify that information that would also be  
>> helpful). This is what you need to set the "grav_boundary_type"  
>> parameter to in your flash.par. Other parameters, "xl_boundary",  
>> "xr_boundary", etc, should be set to outflow.
>>
>> Best,
>>
>> John
>>
>> For hydrodynamics and/or particles, the bou
>> On May 7, 2008, at 8:04 AM, Josef St?ckl wrote:
>>
>>> Hi,
>>>
>>> I'm trying to set up a problem with "outflow" boundary conditions,  
>>> but when I choose this BC type I always get the following message  
>>> in my log:
>>> gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for  
>>> the WORK array
>>>
>>> Looking inside that file seems to suggest that at the moment only  
>>> a few boundary conditions are implemented and not all, which the  
>>> Flash 3 Manual lists. Is there some development version of the  
>>> Grid code available that handles outflow conditions?
>>>
>>> Thanks in advance and best regards to all,
>>>
>>> Josef
>>> <josef_stoeckl.vcf>
>>
>>
>
> <josef_stoeckl.vcf>


From josef.stoeckl at uibk.ac.at  Wed May  7 08:49:33 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 07 May 2008 15:49:33 +0200
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <4821AC6C.3030403@uibk.ac.at>
References: <48219AD1.4040309@uibk.ac.at>	<5b942a610805070606r691177d2obb7203258e53bed0@mail.gmail.com>
	<4821AC6C.3030403@uibk.ac.at>
Message-ID: <4821B36D.4040703@uibk.ac.at>

Hi,

As a follow up question: Is there any specific reason that the Multigrid 
solver doesn't handle "outflow" boundaries (e.g. is it intended) or 
could it be implemented?

Thanks and best regards,
Josef

Josef St?ckl wrote:
> Hi Anshu,
>
> Yes, I'm indeed using the Multigrid solver. I didn't find any mention 
> of this solver not working with "outflow", but I'll have to check 
> again. I wonder though, isn't "grav_boundary_type" the boundary 
> condition used for the self gravity? Because I had set that to 
> "periodic" for my initial tests.
>
> Thanks and best regards,
> Josef
>
>
> Anshu Dubey wrote:
>> It appears that you are using the multigrid solver for gravity in 
>> your simulation.
>> Self gravity in FLASH does not support outflow boundary conditions, 
>> most of the
>> other solvers do. From the setups included with the distribution you 
>> can check out
>> "Sod" and "Sedov", they both use outflow boundary conditions.
>>
>> Anshu
>>
>> On Wed, May 7, 2008 at 7:04 AM, Josef St?ckl 
>> <josef.stoeckl at uibk.ac.at <mailto:josef.stoeckl at uibk.ac.at>> wrote:
>>
>>     Hi,
>>
>>     I'm trying to set up a problem with "outflow" boundary
>>     conditions, but when I choose this BC type I always get the
>>     following message in my log:
>>     gr_hgMapBcType: An unexpected gr_hgBndConditions was requested
>>     for the WORK array
>>
>>     Looking inside that file seems to suggest that at the moment only
>>     a few boundary conditions are implemented and not all, which the
>>     Flash 3 Manual lists. Is there some development version of the
>>     Grid code available that handles outflow conditions?
>>
>>     Thanks in advance and best regards to all,
>>
>>     Josef
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/7075560e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/7075560e/attachment.vcf 

From hudson at mcs.anl.gov  Wed May  7 10:09:06 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Wed, 7 May 2008 10:09:06 -0500
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <48207BDA.102@astro.rug.nl>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
	<48207BDA.102@astro.rug.nl>
Message-ID: <29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>


Seyit,

On May 6, 2008, at 10:40 AM, Seyit Hocuk wrote:

> Hi,
>
> I don't know if anyone else has this, but VisIt 1.9.0 shows my  
> pseudocolor plots completely black. Basically the color profile  
> "Hot" is not working in my case. Even when I try to select "Hot"  
> from colors, VisIt directly crashes. Whenever I change to a  
> different color profile, then it works. Except that there are few  
> random colored blocks showing here and there, also odd.


Can you send me some images?


>
> Btw, there is another thing unmentioned I think. Starting VisIt for  
> FLASH now needs the command "-assume_format FLASH" instead of "- 
> default_format FLASH". "-fallback_format FLASH" also works, but  
> slower.


The release notes describe this a bit.  The fallback format is tried  
AFTER all others; the assumed format is tried BEFORE all others.


>
> Greetz,
> Seyit
>
> ps: I don't see any difference between "mesh_blockandlevel" and  
> "mesh_blockandproc" plots.


There won't be if you visualize all the data.  But, the former allows  
you to create subsets by refinement level and the latter by processor  
number.  (With both, you can create subsets by block.)


>
>>
>> Concerning VisIt:
>>
>> I don't remember if I already announced this, but, with the latest  
>> version of the flash plugin, the variable names for flash data  
>> appear under new, intervening submenus "mesh_blockandlevel" and  
>> "mesh_blockandproc".
>>
>> I needed to add these when, to the original subsetting by blocks  
>> and refinement levels, I added subsetting by blocks and processor  
>> numbers.  I needed to define block-level and block-proc subsetting  
>> pairs, and, to make these both available, I needed the new submenus.
>>
>> I also had added the visualization of the Morton curve, and that's  
>> subset-able both ways as well.
>>
>>
>> Randy.
>>
>>
>>
>
>

Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/97abd09f/attachment.html 

From dubey at flash.uchicago.edu  Wed May  7 10:19:28 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Wed, 7 May 2008 10:19:28 -0500
Subject: [FLASH-USERS] Unsupported boundary condititions
In-Reply-To: <4821B36D.4040703@uibk.ac.at>
References: <48219AD1.4040309@uibk.ac.at>
	<5b942a610805070606r691177d2obb7203258e53bed0@mail.gmail.com>
	<4821AC6C.3030403@uibk.ac.at> <4821B36D.4040703@uibk.ac.at>
Message-ID: <5b942a610805070819n2dbfa5c2td2291a8e361ac7d9@mail.gmail.com>

The multigrid solver in FLASH is for an elliptic equation, outflow
boundaries make no sense for this equation.

Anshu

On Wed, May 7, 2008 at 8:49 AM, Josef St?ckl <josef.stoeckl at uibk.ac.at>
wrote:

>  Hi,
>
> As a follow up question: Is there any specific reason that the Multigrid
> solver doesn't handle "outflow" boundaries (e.g. is it intended) or could it
> be implemented?
>
> Thanks and best regards,
> Josef
>
> Josef St?ckl wrote:
>
> Hi Anshu,
>
> Yes, I'm indeed using the Multigrid solver. I didn't find any mention of
> this solver not working with "outflow", but I'll have to check again. I
> wonder though, isn't "grav_boundary_type" the boundary condition used for
> the self gravity? Because I had set that to "periodic" for my initial tests.
>
> Thanks and best regards,
> Josef
>
>
> Anshu Dubey wrote:
>
> It appears that you are using the multigrid solver for gravity in your
> simulation.
> Self gravity in FLASH does not support outflow boundary conditions, most
> of the
> other solvers do. From the setups included with the distribution you can
> check out
> "Sod" and "Sedov", they both use outflow boundary conditions.
>
> Anshu
>
> On Wed, May 7, 2008 at 7:04 AM, Josef St?ckl <josef.stoeckl at uibk.ac.at>
> wrote:
>
> Hi,
>
> I'm trying to set up a problem with "outflow" boundary conditions, but
> when I choose this BC type I always get the following message in my log:
> gr_hgMapBcType: An unexpected gr_hgBndConditions was requested for the
> WORK array
>
> Looking inside that file seems to suggest that at the moment only a few
> boundary conditions are implemented and not all, which the Flash 3 Manual
> lists. Is there some development version of the Grid code available that
> handles outflow conditions?
>
> Thanks in advance and best regards to all,
>
> Josef
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/b1a95ed0/attachment.html 

From seyit at astro.rug.nl  Wed May  7 10:42:23 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Wed, 07 May 2008 17:42:23 +0200
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
	<48207BDA.102@astro.rug.nl>
	<29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>
Message-ID: <4821CDDF.9060207@astro.rug.nl>

Hi Randy,


>
>> Hi,
>>
>> I don't know if anyone else has this, but VisIt 1.9.0 shows my 
>> pseudocolor plots completely black. Basically the color profile "Hot" 
>> is not working in my case. Even when I try to select "Hot" from 
>> colors, VisIt directly crashes. Whenever I change to a different 
>> color profile, then it works. Except that there are few random 
>> colored blocks showing here and there, also odd.
>
> Can you send me some images?

An image of the weird points showing on the image is added. It is like 
some bad pixels. These aren't showing in older versions of Visit.

I can't send you images of black screen anymore, because, I made 'Hot 
desaturated' color profile standard now, and whenever I try to select 
'Hot', VisIt immediately crashes every time.


G'day,
Seyit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: visit0001.jpeg
Type: image/jpeg
Size: 76486 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/0e51d571/attachment-0001.jpeg 

From hudson at mcs.anl.gov  Wed May  7 11:34:17 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Wed, 7 May 2008 11:34:17 -0500
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <4821CDDF.9060207@astro.rug.nl>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
	<48207BDA.102@astro.rug.nl>
	<29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>
	<4821CDDF.9060207@astro.rug.nl>
Message-ID: <51EA5951-523C-4721-AAC1-5D0EB462930C@mcs.anl.gov>


Seyit,

Did you rename your ~/.visit directory so the new visit would start  
with a fresh config?  If not, try it.  Occasionally, that will clear  
up some problems.

I assume the vexing, odd blocks are the blue, green and orange ones  
around the rim.  Assuming you're not mapping color logarithmically,  
the scalar values for those colors are about 5e-21, 8e-21 and 1e-20,  
resp., if I did my cypherin' right.  Are you sure your data doesn't  
contain those values?  Or is the odd thing just having considerably- 
lower values right next to the generally-higher ones?

You're using a different colormap than you used to, right?  Could  
that explain the different appearance?

Did the pseudocolor plot created by the older visit look so  
pixelated?  If not, you probably need to select "Nodal" centering,  
instead of "Natural" or "Zonal", at the top of the "Pseudocolor plot  
attributes" window.


On May 7, 2008, at 10:42 AM, Seyit Hocuk wrote:

> Hi Randy,
>
>
>>
>>> Hi,
>>>
>>> I don't know if anyone else has this, but VisIt 1.9.0 shows my  
>>> pseudocolor plots completely black. Basically the color profile  
>>> "Hot" is not working in my case. Even when I try to select "Hot"  
>>> from colors, VisIt directly crashes. Whenever I change to a  
>>> different color profile, then it works. Except that there are few  
>>> random colored blocks showing here and there, also odd.
>>
>> Can you send me some images?
>
> An image of the weird points showing on the image is added. It is  
> like some bad pixels. These aren't showing in older versions of Visit.
>
> I can't send you images of black screen anymore, because, I made  
> 'Hot desaturated' color profile standard now, and whenever I try to  
> select 'Hot', VisIt immediately crashes every time.
>
>
> G'day,
> Seyit<visit0001.jpeg>

Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080507/65e1fb38/attachment.html 

From seyit at astro.rug.nl  Thu May  8 05:44:34 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Thu, 08 May 2008 12:44:34 +0200
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <3AB5161C-8E34-4F08-AAA6-B8D352DE6A97@mcs.anl.gov>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
	<48207BDA.102@astro.rug.nl>
	<29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>
	<4821CDDF.9060207@astro.rug.nl>
	<51EA5951-523C-4721-AAC1-5D0EB462930C@mcs.anl.gov>
	<4821E059.4010602@astro.rug.nl>
	<3AB5161C-8E34-4F08-AAA6-B8D352DE6A97@mcs.anl.gov>
Message-ID: <4822D992.8080105@astro.rug.nl>

Hi Randy,

Yes indeed that solves the problem. Now it is without the bad blocks, 
which was indeed coming from the parent blocks.

Thanks man.

The only unfortunate thin is that I repeatedly have to do this now. 
Especially because I have a adaptive mesh refinement, I cannot just 
ignore most of the parent blocks.

Greetz,
Seyit



Randy Hudson wrote:
>
> O.K.  One other idea:  use the Subset window to select just the 
> highest refinement level to visualize and see if it looks better.
>
> To do that, you have to first create a Pseudocolor plot via the 
> "mesh_blockandlevel" submenu.
> Then, 
>    in the Active plots panel in the main window, click the icon just 
> to the left of the plot name to bring up the Subset window
>    in the Subset window, click "Levels" in the left-hand panel
>    in the next panel, which should now list the levels, all checked, 
> uncheck the highest level
>    below the list of levels, click the first "Reverse" button (the one 
> next to "All sets")
>    click "Apply" to apply this selection of just highest ref. level
>
> Now, when you display the plot, it will only be of that level.
>
> Let me know if that helps.
>
>
> On May 7, 2008, at 12:01 PM, Seyit Hocuk wrote:
>
>> Randy Hudson wrote:
>>>
>>> Seyit,
>>>
>>> Did you rename your ~/.visit directory so the new visit would start 
>>> with a fresh config?  If not, try it.  Occasionally, that will clear 
>>> up some problems.
>> I was actually thinking and doing just that. The result is that the 
>> "Hot" color profile is back and working. However, I still have the 
>> odd pixels. I didn't have them with the other versions of VisIt.
>>>
>>> I assume the vexing, odd blocks are the blue, green and orange ones 
>>> around the rim.  Assuming you're not mapping color logarithmically, 
>>> the scalar values for those colors are about 5e-21, 8e-21 and 1e-20, 
>>> resp., if I did my cypherin' right.  Are you sure your data doesn't 
>>> contain those values?  Or is the odd thing just having 
>>> considerably-lower values right next to the generally-higher ones?
>> I am pretty sure those are not in my data. I send you a lot of images 
>> now.
>>>
>>> You're using a different colormap than you used to, right?  Could 
>>> that explain the different appearance?
>> Unfortunately no.
>>>
>>> Did the pseudocolor plot created by the older visit look so 
>>> pixelated?  If not, you probably need to select "Nodal" centering, 
>>> instead of "Natural" or "Zonal", at the top of the "Pseudocolor plot 
>>> attributes" window.
>> Pixelated is because this is from a low resolution simulation. Nodal 
>> makes things smoother, but not solving the problem nor is zonal.
>>
>>
>> Seyit
>>
>>>
>>>
>>> On May 7, 2008, at 10:42 AM, Seyit Hocuk wrote:
>>>
>>>> Hi Randy,
>>>>
>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I don't know if anyone else has this, but VisIt 1.9.0 shows my 
>>>>>> pseudocolor plots completely black. Basically the color profile 
>>>>>> "Hot" is not working in my case. Even when I try to select "Hot" 
>>>>>> from colors, VisIt directly crashes. Whenever I change to a 
>>>>>> different color profile, then it works. Except that there are few 
>>>>>> random colored blocks showing here and there, also odd.
>>>>>
>>>>> Can you send me some images?
>>>>
>>>> An image of the weird points showing on the image is added. It is 
>>>> like some bad pixels. These aren't showing in older versions of Visit.
>>>>
>>>> I can't send you images of black screen anymore, because, I made 
>>>> 'Hot desaturated' color profile standard now, and whenever I try to 
>>>> select 'Hot', VisIt immediately crashes every time.
>>>>
>>>>
>>>> G'day,
>>>> Seyit<visit0001.jpeg>
>>>
>>> Randy.
>>>
>>>
>>>
>>
>> <visit20000.jpeg><visit30000.jpeg><visit40000.jpeg><visit50000.jpeg><visit60000.jpeg><visit70000.jpeg><visit80000.jpeg><visit90000.jpeg>
>
> Randy.
>
>
>


From hudson at mcs.anl.gov  Thu May  8 08:46:16 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Thu, 8 May 2008 08:46:16 -0500
Subject: [FLASH-USERS] VisIt - New submenus for flash data
In-Reply-To: <4822D992.8080105@astro.rug.nl>
References: <03DBA738-8765-4D11-9670-A35FFC80D853@mcs.anl.gov>
	<48207BDA.102@astro.rug.nl>
	<29F900AB-34DA-4291-AC6B-454FFADA7597@mcs.anl.gov>
	<4821CDDF.9060207@astro.rug.nl>
	<51EA5951-523C-4721-AAC1-5D0EB462930C@mcs.anl.gov>
	<4821E059.4010602@astro.rug.nl>
	<3AB5161C-8E34-4F08-AAA6-B8D352DE6A97@mcs.anl.gov>
	<4822D992.8080105@astro.rug.nl>
Message-ID: <2E12C774-0AF5-49E9-A478-8BAC6243D588@mcs.anl.gov>


Seyit,

It seems as though you're not the only one seeing this effect.  I've  
spoken to the visit people, and they're not yet sure of the cause.   
I'll keep working on it.


On May 8, 2008, at 5:44 AM, Seyit Hocuk wrote:

> Hi Randy,
>
> Yes indeed that solves the problem. Now it is without the bad  
> blocks, which was indeed coming from the parent blocks.
>
> Thanks man.
>
> The only unfortunate thin is that I repeatedly have to do this now.  
> Especially because I have a adaptive mesh refinement, I cannot just  
> ignore most of the parent blocks.
>
> Greetz,
> Seyit
>
>
>
> Randy Hudson wrote:
>>
>> O.K.  One other idea:  use the Subset window to select just the  
>> highest refinement level to visualize and see if it looks better.
>>
>> To do that, you have to first create a Pseudocolor plot via the  
>> "mesh_blockandlevel" submenu.
>> Then,    in the Active plots panel in the main window, click the  
>> icon just to the left of the plot name to bring up the Subset window
>>    in the Subset window, click "Levels" in the left-hand panel
>>    in the next panel, which should now list the levels, all  
>> checked, uncheck the highest level
>>    below the list of levels, click the first "Reverse" button (the  
>> one next to "All sets")
>>    click "Apply" to apply this selection of just highest ref. level
>>
>> Now, when you display the plot, it will only be of that level.
>>
>> Let me know if that helps.
>>
>>
>> On May 7, 2008, at 12:01 PM, Seyit Hocuk wrote:
>>
>>> Randy Hudson wrote:
>>>>
>>>> Seyit,
>>>>
>>>> Did you rename your ~/.visit directory so the new visit would  
>>>> start with a fresh config?  If not, try it.  Occasionally, that  
>>>> will clear up some problems.
>>> I was actually thinking and doing just that. The result is that  
>>> the "Hot" color profile is back and working. However, I still  
>>> have the odd pixels. I didn't have them with the other versions  
>>> of VisIt.
>>>>
>>>> I assume the vexing, odd blocks are the blue, green and orange  
>>>> ones around the rim.  Assuming you're not mapping color  
>>>> logarithmically, the scalar values for those colors are about  
>>>> 5e-21, 8e-21 and 1e-20, resp., if I did my cypherin' right.  Are  
>>>> you sure your data doesn't contain those values?  Or is the odd  
>>>> thing just having considerably-lower values right next to the  
>>>> generally-higher ones?
>>> I am pretty sure those are not in my data. I send you a lot of  
>>> images now.
>>>>
>>>> You're using a different colormap than you used to, right?   
>>>> Could that explain the different appearance?
>>> Unfortunately no.
>>>>
>>>> Did the pseudocolor plot created by the older visit look so  
>>>> pixelated?  If not, you probably need to select "Nodal"  
>>>> centering, instead of "Natural" or "Zonal", at the top of the  
>>>> "Pseudocolor plot attributes" window.
>>> Pixelated is because this is from a low resolution simulation.  
>>> Nodal makes things smoother, but not solving the problem nor is  
>>> zonal.
>>>
>>>
>>> Seyit
>>>
>>>>
>>>>
>>>> On May 7, 2008, at 10:42 AM, Seyit Hocuk wrote:
>>>>
>>>>> Hi Randy,
>>>>>
>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I don't know if anyone else has this, but VisIt 1.9.0 shows  
>>>>>>> my pseudocolor plots completely black. Basically the color  
>>>>>>> profile "Hot" is not working in my case. Even when I try to  
>>>>>>> select "Hot" from colors, VisIt directly crashes. Whenever I  
>>>>>>> change to a different color profile, then it works. Except  
>>>>>>> that there are few random colored blocks showing here and  
>>>>>>> there, also odd.
>>>>>>
>>>>>> Can you send me some images?
>>>>>
>>>>> An image of the weird points showing on the image is added. It  
>>>>> is like some bad pixels. These aren't showing in older versions  
>>>>> of Visit.
>>>>>
>>>>> I can't send you images of black screen anymore, because, I  
>>>>> made 'Hot desaturated' color profile standard now, and whenever  
>>>>> I try to select 'Hot', VisIt immediately crashes every time.
>>>>>
>>>>>
>>>>> G'day,
>>>>> Seyit<visit0001.jpeg>
>>>>
>>>> Randy.
>>>>
>>>>
>>>>
>>>
>>> <visit20000.jpeg><visit30000.jpeg><visit40000.jpeg><visit50000.jpeg> 
>>> <visit60000.jpeg><visit70000.jpeg><visit80000.jpeg><visit90000.jpeg>
>>
>> Randy.
>>
>>
>>
>
>

Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080508/1972da6e/attachment.html 

From jfg at ucolick.org  Tue May 13 14:35:33 2008
From: jfg at ucolick.org (James Guillochon)
Date: Tue, 13 May 2008 12:35:33 -0700
Subject: [FLASH-USERS] Possible Restart Bug in 3.0
Message-ID: <4829ED85.8010605@ucolick.org>

Hey guys,

It seems that the velz variable is getting shifted relative to the other 
variables when I restart a simulation. This shift appears to be equal to 
the nzb variable, or 8 blocks, at the highest refinement level. I have 
attached two screenshots: The first is prior to the restart, the second 
is immediately after the restart.

The only variable that changes between restarts is the max refinement 
level; however the shift in velz is visible before the grid is refined. 
No other variables are shifted. This is a real problem for me since my 
problem assumes symmetry about the z axis!

Any ideas guys?

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: visit0000.png
Type: image/png
Size: 44990 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080513/1fee878f/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: visit0001.png
Type: image/png
Size: 45298 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080513/1fee878f/attachment-0003.png 

From dubey at flash.uchicago.edu  Tue May 13 14:43:26 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Tue, 13 May 2008 14:43:26 -0500
Subject: [FLASH-USERS] Possible Restart Bug in 3.0
In-Reply-To: <4829ED85.8010605@ucolick.org>
References: <4829ED85.8010605@ucolick.org>
Message-ID: <5b942a610805131243r2938b515y2ebc2a332e203d26@mail.gmail.com>

Hi James,

Can you share your setup, flash.par and any other customized file with us ?
We have never encountered the problem
that you are seeing, and we'd really like to be able to reproduce it
ourselves to figure out what is going on.

Anshu

On Tue, May 13, 2008 at 2:35 PM, James Guillochon <jfg at ucolick.org> wrote:

> Hey guys,
>
> It seems that the velz variable is getting shifted relative to the other
> variables when I restart a simulation. This shift appears to be equal to the
> nzb variable, or 8 blocks, at the highest refinement level. I have attached
> two screenshots: The first is prior to the restart, the second is
> immediately after the restart.
>
> The only variable that changes between restarts is the max refinement
> level; however the shift in velz is visible before the grid is refined. No
> other variables are shifted. This is a real problem for me since my problem
> assumes symmetry about the z axis!
>
> Any ideas guys?
>
> --
> James Guillochon
> Department of Astronomy & Astrophysics
> University of California, Santa Cruz
> jfg at ucolick.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080513/c8818285/attachment.html 

From jfg at ucolick.org  Tue May 13 16:01:45 2008
From: jfg at ucolick.org (James Guillochon)
Date: Tue, 13 May 2008 14:01:45 -0700
Subject: [FLASH-USERS] Possible Restart Bug in 3.0
In-Reply-To: <5b942a610805131243r2938b515y2ebc2a332e203d26@mail.gmail.com>
References: <4829ED85.8010605@ucolick.org>
	<5b942a610805131243r2938b515y2ebc2a332e203d26@mail.gmail.com>
Message-ID: <482A01B9.4030002@ucolick.org>

I just checked and the problem occurs even if the max refinement level 
is the same before and after the restart.

I've attached two flash.par files, the first is from the initial run, 
the second is for the restarted run. I've modified the following 
built-in files:

Gravity_accelAtCoords.F90
Gravity_accelListOfBlocks.F90
Gravity_accelOneRow.F90
Gravity_data.F90
Gravity_init.F90
Gravity_potentialListOfBlocks.F90
Grid_data.F90
Grid_init.F90
Grid_markRefineDerefine.F90
Simulation_data.F90
Simulation_initBlock.F90
Simulation_init.F90

Which in particular would you like me to attach? (I don't want to attach 
all of them)

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org


Anshu Dubey wrote:
> Hi James,
> 
> Can you share your setup, flash.par and any other customized file with 
> us ? We have never encountered the problem
> that you are seeing, and we'd really like to be able to reproduce it 
> ourselves to figure out what is going on.
> 
> Anshu
> 
> On Tue, May 13, 2008 at 2:35 PM, James Guillochon <jfg at ucolick.org 
> <mailto:jfg at ucolick.org>> wrote:
> 
>     Hey guys,
> 
>     It seems that the velz variable is getting shifted relative to the
>     other variables when I restart a simulation. This shift appears to
>     be equal to the nzb variable, or 8 blocks, at the highest refinement
>     level. I have attached two screenshots: The first is prior to the
>     restart, the second is immediately after the restart.
> 
>     The only variable that changes between restarts is the max
>     refinement level; however the shift in velz is visible before the
>     grid is refined. No other variables are shifted. This is a real
>     problem for me since my problem assumes symmetry about the z axis!
> 
>     Any ideas guys?
> 
>     -- 
>     James Guillochon
>     Department of Astronomy & Astrophysics
>     University of California, Santa Cruz
>     jfg at ucolick.org <mailto:jfg at ucolick.org>
> 
> 
> !DSPAM:10135,4829ef7c2382245126300!
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flash_after_restart.par
Url: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080513/c6c49034/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: flash_before_restart.par
Url: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080513/c6c49034/attachment-0001.pl 

From josef.stoeckl at uibk.ac.at  Wed May 14 03:25:31 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 14 May 2008 10:25:31 +0200
Subject: [FLASH-USERS] Boundary conditions of the Multigrid Solver/Gravity
Message-ID: <482AA1FB.8020309@uibk.ac.at>

Hello,

I'm having a small problem with the Multigrid solver or the Gravity 
Multigrid unit respectively. According to the manual, the supported 
boundary conditions for the Multigrid gravity unit are "periodic, 
Dirichlet, given-value, and isolated". However, when I try to use any 
value other than periodic or isolated for the "grav_boundary_type", I 
get the following error message:

Gravity_init: unrecognized or unsupported gravity boundary type

Looking at Gravity_init.F90 one can see that the routine only allows 
isolated or periodic at the moment. So I'm wondering if the other 
boundary conditions are still to be implemented or if there is any 
version with those enabled available?

I also wonder, if it is possible to have independent boundary conditions 
for the Hydro, Gravity and Particles units? So far I have found that the 
[xyz][lr]_boundary_type controls the overall boundary conditions for the 
Hydro, but the gravity part of the Hydro is controlled by 
grav_boundary_type (which makes a lot of sense). In gr_hgMapBcType.F90 
of the Multigrid solver however only very few of the possible 
combinations of these two settings are handled. So I'm wondering, if it 
would be possible to extend this to handle those settings more 
independently/generally or if there were some problems arising when 
adapting this routine to accept more cases?

Would it require a great change in the MG solver to e.g. combine a Hydro 
"outflow" (or inflow) condition, so that material with low density and 
temperature can come in and out of the computational domain, with a 
gravity "periodic" condition?

Thanks in advance and best regards,

Josef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080514/6e9026a2/attachment.vcf 

From dubey at flash.uchicago.edu  Wed May 14 13:46:39 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Wed, 14 May 2008 13:46:39 -0500
Subject: [FLASH-USERS] Boundary conditions of the Multigrid
	Solver/Gravity
In-Reply-To: <482AA1FB.8020309@uibk.ac.at>
References: <482AA1FB.8020309@uibk.ac.at>
Message-ID: <5b942a610805141146w1f3c2242s3a6b5c60db18b006@mail.gmail.com>

Hi Josef,

The answers to your questions are inlined

On Wed, May 14, 2008 at 3:25 AM, Josef St?ckl <josef.stoeckl at uibk.ac.at>
wrote:

> Hello,
>
> I'm having a small problem with the Multigrid solver or the Gravity
> Multigrid unit respectively. According to the manual, the supported boundary
> conditions for the Multigrid gravity unit are "periodic, Dirichlet,
> given-value, and isolated". However, when I try to use any value other than
> periodic or isolated for the "grav_boundary_type", I get the following error
> message:


>
> Gravity_init: unrecognized or unsupported gravity boundary type
>
> Looking at Gravity_init.F90 one can see that the routine only allows
> isolated or periodic at the moment. So I'm wondering if the other boundary
> conditions are still to be implemented or if there is any version with those
> enabled available?

There is implementation for Dirichlet and Neumann boundary conditions, but
they have never been used by any setup in FLASH,
so they haven't been tested as thoroughly as we'd like. You can enable them
by modifying the Gravity_init routine.

>
>
> I also wonder, if it is possible to have independent boundary conditions
> for the Hydro, Gravity and Particles units? So far I have found that the
> [xyz][lr]_boundary_type controls the overall boundary conditions for the
> Hydro, but the gravity part of the Hydro is controlled by grav_boundary_type
> (which makes a lot of sense). In gr_hgMapBcType.F90 of the Multigrid solver
> however only very few of the possible combinations of these two settings are
> handled. So I'm wondering, if it would be possible to extend this to handle
> those settings more independently/generally or if there were some problems
> arising when adapting this routine to accept more cases?
>
> Would it require a great change in the MG solver to e.g. combine a Hydro
> "outflow" (or inflow) condition, so that material with low density and
> temperature can come in and out of the computational domain, with a gravity
> "periodic" condition?


Gravity and Hydro first; you can combine all available Hydro boundaries with
Gravity boundaries as long as neither is periodic.
This is a current paramesh limitation where  if boundary conditions for the
mesh are specified as periodic, control is never
passed to the user. And there is no way of specifying different boundary
conditions for different data structures. You can extend
the possible combinations of other boundary types by getting rid of the test
for the mesh boundary conditions in gr_hgMapBcType.
Specifically the outer case statement that checks for bcTypeFromGrid. We are
looking at the possibility of enabling periodic
boundary conditions in multigrid even when the mesh has some other boundary
conditions. That may take a little time because
it is non-trivial.

As for the particles, it will be relatively easy to do in terms of the code
since they are not moved by paramesh at all. We can
modify the code where by default particles get the boundary conditions from
the grid, but have a combination of runtime
parameters, one that specifies that grid boundaries should be overridden,
and then six more to specify the actual conditions.
Please let me know how urgently you need this capability, we will respond
accordingly.

>
>
> Thanks in advance and best regards,
>
> Josef
>

Anshu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080514/228a5a9c/attachment.html 

From dubey at flash.uchicago.edu  Wed May 14 17:56:59 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Wed, 14 May 2008 17:56:59 -0500
Subject: [FLASH-USERS] Possible Restart Bug in 3.0
In-Reply-To: <482A01B9.4030002@ucolick.org>
References: <4829ED85.8010605@ucolick.org>
	<5b942a610805131243r2938b515y2ebc2a332e203d26@mail.gmail.com>
	<482A01B9.4030002@ucolick.org>
Message-ID: <5b942a610805141556p20c0ebc3j3624497cac8090c0@mail.gmail.com>

James,

We will definitely need all the Simulation_ and Grid_ files to have any
chance of finding out
the problem. However, without having all the files it is not clear that we
can solve your problem, because
we run many problems with restart in our nightly test suite, and all of them
start transparently. It seems
very likely that your restart issue is specific to your problem.

If you are really uncomfortable about sharing the files, then you can try
the following steps, at each step
making sure that you have transparent restart :
1. Start with a simple problem like Sedov.
2. Add self gravity to it.
3. Add your custom gravity routines.
4. Start your own problem with gravity turned off, and default
mark_refine_derefine
5. Add each custom component one by one.

That is basically the strategy I would use for identifying the problem.

Let me also assure you that if you were to give the files to us, only one
person will have access to them,
and he/she will delete them as soon as they are done with them.

Anshu

On Tue, May 13, 2008 at 4:01 PM, James Guillochon <jfg at ucolick.org> wrote:

> I just checked and the problem occurs even if the max refinement level is
> the same before and after the restart.
>
> I've attached two flash.par files, the first is from the initial run, the
> second is for the restarted run. I've modified the following built-in files:
>
> Gravity_accelAtCoords.F90
> Gravity_accelListOfBlocks.F90
> Gravity_accelOneRow.F90
> Gravity_data.F90
> Gravity_init.F90
> Gravity_potentialListOfBlocks.F90
> Grid_data.F90
> Grid_init.F90
> Grid_markRefineDerefine.F90
> Simulation_data.F90
> Simulation_initBlock.F90
> Simulation_init.F90
>
> Which in particular would you like me to attach? (I don't want to attach
> all of them)
>
> --
> James Guillochon
> Department of Astronomy & Astrophysics
> University of California, Santa Cruz
> jfg at ucolick.org
>
>
> Anshu Dubey wrote:
>
>> Hi James,
>>
>> Can you share your setup, flash.par and any other customized file with us
>> ? We have never encountered the problem
>> that you are seeing, and we'd really like to be able to reproduce it
>> ourselves to figure out what is going on.
>>
>> Anshu
>>
>> On Tue, May 13, 2008 at 2:35 PM, James Guillochon <jfg at ucolick.org<mailto:
>> jfg at ucolick.org>> wrote:
>>
>>    Hey guys,
>>
>>    It seems that the velz variable is getting shifted relative to the
>>    other variables when I restart a simulation. This shift appears to
>>    be equal to the nzb variable, or 8 blocks, at the highest refinement
>>    level. I have attached two screenshots: The first is prior to the
>>    restart, the second is immediately after the restart.
>>
>>    The only variable that changes between restarts is the max
>>    refinement level; however the shift in velz is visible before the
>>    grid is refined. No other variables are shifted. This is a real
>>    problem for me since my problem assumes symmetry about the z axis!
>>
>>    Any ideas guys?
>>
>>    --    James Guillochon
>>    Department of Astronomy & Astrophysics
>>    University of California, Santa Cruz
>>    jfg at ucolick.org <mailto:jfg at ucolick.org>
>>
>>
>> !DSPAM:10135,4829ef7c2382245126300!
>>
>
> lrefine_min             > lrefine_max             >
>
> basenm                  > restart                 > checkpointFileIntervalTime > checkpointFileNumber > plotFileIntervalTime    >
> xmax                    > ymax                    > zmax                    >
> ptmass                  > ptxpos                  > ptypos                  > ptzpos                  >
> small > smalle > smallt > smallu > smallx > smally > smlrho > smallp > #
> #cfl > #cvisc > #iplm > nriem > #eos_maxNewton > #convertToConsvdForMeshCalls > dtinit > #dtmin > #dtmax > #memory_stat_freq >
> nend                    > tmax                    >
> gamma                   >
> eintSwitch              > #if beta is < 0, the code uses periDist instead.
> sim_periBeta            > sim_periDist            > sim_periTime            > sim_rhoAmbient          > sim_pAmbient            > sim_xctr                > sim_yctr                > sim_zctr                > sim_nsubzones           >
>
> xl_boundary_type        > xr_boundary_type        > yl_boundary_type        > yr_boundary_type        > zl_boundary_type        > zr_boundary_type        > grav_boundary_type      > mpole_lmax              > #useGravity              >
> plot_var_1              > plot_var_2              > plot_var_3              > plot_var_4              > plot_var_5              > plot_var_6              >
> refine_var_1            > #refine_var_2            > refine_filter_1         > #refine_filter_2         > refine_val_cutoff_1     >
> lrefine_min             > lrefine_max             >
>
> basenm                  > restart                 > checkpointFileIntervalTime > plotFileIntervalTime    >
> xmax                    > ymax                    > zmax                    >
> ptmass                  > ptxpos                  > ptypos                  > ptzpos                  >
> small > smalle > smallt > smallu > smallx > smally > smlrho > smallp > #
> #cfl > #cvisc > #iplm > nriem > #eos_maxNewton > #convertToConsvdForMeshCalls > dtinit > #dtmin > #dtmax > #memory_stat_freq >
> nend                    > tmax                    >
> gamma                   >
> eintSwitch              > #if beta is < 0, the code uses periDist instead.
> sim_periBeta            > sim_periDist            > sim_periTime            > sim_rhoAmbient          > sim_pAmbient            > sim_xctr                > sim_yctr                > sim_zctr                > sim_nsubzones           >
>
> xl_boundary_type        > xr_boundary_type        > yl_boundary_type        > yr_boundary_type        > zl_boundary_type        > zr_boundary_type        > grav_boundary_type      > mpole_lmax              > #useGravity              >
> plot_var_1              > plot_var_2              > plot_var_3              > plot_var_4              > plot_var_5              > plot_var_6              >
> refine_var_1            > #refine_var_2            > refine_filter_1         > #refine_filter_2         > refine_val_cutoff_1     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080514/c8622d70/attachment-0001.html