Closed dhilburn closed 6 years ago
Hi @dhilburn and thanks for your report! Please give us some time to try to reproduce the problem and we'll get back to you!
Github sent that email to all collabs on the Dusty repo I think (I got it). First I thought it might be a student of yours, but no(?) R.
On 01/09/2018 12:40 PM, Zeljko Ivezic wrote:
Hi @dhilburn https://github.com/dhilburn and thanks for your report! Please give us some time to try to reproduce the problem and we'll get back to you!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ivezic/dusty/issues/1#issuecomment-356358747, or mute the thread https://github.com/notifications/unsubscribe-auth/AHMEGgbabY5OzTykT32BRwf-KP8NoS6zks5tI6SjgaJpZM4RV9DM.
-- Encrypted e-mail is most welcome. My GPG public key: https://www.noao.edu/staff/nikutta/robertnikutta.asc Key fingerprint: E309 CEA4 6653 4D2C 0C7E 59BB 9E79 566F 3CDA D34F
No, just a hobbyist. My brother is doing his thesis on variable stars using Dusty, and let me play around with some of his data. He's using matlab to determine which Dusty parameter values provide results similar to observations he's gathered from radio telescopes. I work in AI coding and dabble in machine learning, so I was interested in using machine learning techniques to do the same job. He's using the Linux build (v2), but I'm working in Windows. Originally, I was going to just use the new Linux runtime in Windows 10, but it's even easier to just use the Windows version if it works. It almost does, but not quite. As a programmer, I felt like I couldn't just leave it with the bug hanging about, so here we are. It looks like all of the input files in the examples directory use POWD, so it makes sense why this bug was never caught.
Incidentally, it looks like when using Scale = T1 (as the attached test.inp file does), the utot() array is used before it is initialized, causing a divide-by-zero error (it is all zeros). The utot() array is accessed in Find_Text() in kernel.f90 at line 2105. Find_Text() was, in this case, called from Rad_Transf() in kernel.f90 at line 1231. It looks like utot() gets initialized a bit later in the Find_Diffuse() call in Rad_Transf() in kernel.f90 at line 1236.
@dhilburn Frank just checked in several fixes that hopefully address:
Could you perhaps update your code (master branch) and verify that it's all fixed now? Many thanks in advance!
PS Given your interest in machine learning, please check out http://www.astroml.org
Thanks so much! I'll pull it down tonight and check it out. =)
It works! Thanks so much for your help.
Hello. I'm attempting to use your Dusty application on Windows. I've downloaded the .zip file from here and run compile.bat. I fixed a compiler warning by changing ./sources/dusty.f90, line 100 to
double precision, allocatable :: tau(:)
However, if I run my test.inp file (see attached test.zip file) with density type = RDW, dusty.exe crashes with a memory access exception. I've tracked the problem to a couple of places so far. In ./sources/inout.f90 at line 602 (once dusty has detected that we're using RDW), it looks like we're accessing an unallocated ptr array. I've fixed this bit by allocating ptr(2) at line 601:
if (allocated(ptr)) deallocate(ptr)
allocate(ptr(2))
ptr = 0
I've also found that an uninitialized variable
nY
is used as a loop max in Ygrid() in ./sources/kernel.f90 at line 560. I'm still trying to figure out whatnY
should be in this case to fix it. If you guys have any recommendations, I'd greatly appreciate it.Incidentally, using density type = RDWA works, though it only outputs one model (rather than the number I've specified via
number of models
).I'm running dusty with the command line:
dusty.exe ./test/test.inp 2
test.zip