Hello,

I am currently a grad student using PLUTO to do some 3D hydro sims as part of my PhD. My problem is complex and requires 3D and adaptive mesh. I have coded up my problem and have tested it using the regular version of PLUTO without Chombo/AMR and everything works beautifully. However, I have discovered what I believe is a major bug in the Chombo/AMR version of PLUTO and was wondering if anyone could offer some help.

The bug appears to be at the end of the file PatchUnsplit.cpp (in the /PLUTO/Src/Chombo directoy) in the function SET_BOUNDARY. This is the part of the code that sets the boundary conditions at each time step. The bug isn't so much a bug as a missing section of code. It looks like only the physical boundaries of the code are being updated, and nothing interior to the boundaries is updated at all. This is a big problem for anyone who is using user defined boundary conditions with side==0 (defined in the function USERDEF_BOUNDARY in the init.c file, see PLUTO's userguide) like myself since the computational domain after each time step doesn't get updated with the new values as defined in USERDEF_BOUNDARY. I'm pretty sure what needs to be done is to convert all physical values between the boundaries back into conservative ones after the call to the BOUNDARY function in SET_BOUNDARY in PatchUnsplit.cpp. However, I have tried everything I can think of to try and do this and fix things, but nothing works, I keep getting NANs in several grid cells after a few time steps.

I know that this is a real issue with PLUTO and not my code as I have run several simple test problems both with and without Chombo using user defined boundary conditions and I get completely wrong results when using Chombo, while I get the correct solution if I use the regular version of PLUTO. If anyone else has experience with user defined boundary conditions in the Chombo version of PLUTO or has already encountered and fixed this problem, your help would be much appreciated. If I discover a fix in the meantime, I'll post it back here. Thanks a lot.

Hi all,

An update concerning this bug. I just received an email reply from Andrea Mignone who tells me that this is indeed a bug and that it has been added to the TODO-list, so, it should get fixed in the next release of the code. I have implemented a temporary fix that seems to work for my problem. If anyone is interested, let me know. Thanks.