NewSocialMap Output Bugged on Reload

[GoogleCodeExporter]

Upon a reload, all files are copied over from the backup. However, if some 
dispersers in the year have established home ranges while others are still 
dispersing, any "NewSocialMaps" from the backup are essentially ignored.

Attached are a backup folder and the output from a run restarting from that 
backup. In the 2014 folders, you can see the NewSocialMap38 in the backup as 
well as copied over to the new output folder. But if you take a closer look at 
Map38 and the newly produced Map43 you can see that map38 is essentially 
ignored. 

In map38 you can see dispersers 38, 41, and 42 have established home ranges. 
But in map 43 you can only see dispersers 40 and 43 with home ranges. These two 
established home ranges post-reload. From the text output you can see 
dispersers 38, 41, and 42 are still alive. They just aren't being shown on the 
map.

It's probably just an issue of needing to change some file structure for how 
things are loaded and written out after a reload.

Logs from this run are also attached.

You can replicate this by backing up and restarting any simulation where a 
portion of the dispersers have already established home ranges.

Original issue reported on code.google.com by acohe...@gmail.com on 15 May 2014 at 8:20

Attachments:

• SocialMapReload.zip

[GoogleCodeExporter]

Alex

I am a bit short of time.  To speed this up, please send the xml file to load.  
And exact instructions when to break and reload.  

cheers

bob

Original comment by ran...@mwwb.net on 17 May 2014 at 3:59

[GoogleCodeExporter]

Original comment by ran...@mwwb.net on 19 May 2014 at 12:28

• Changed state: Accepted

[GoogleCodeExporter]

Update to the issue since you have made progress on it.

When you save out the socialmap to load, the logic only works for one backup 
and reload.

Updated Problem: When you reload a run, it no longer saves out the latest 
social map like it does on a normal run.

Look at the two backup folders I attached. In the first you can see 
NewSocialMap38 saved in map.xml. This is the current social map and reloading 
from this folder will put everything at the right point.

But look at the second backup folder. If you look in the 2014 folder you can 
see NewSocialMap39 is the current map (a new disperser established a home) but 
if you look at the map.xml it still lists NewSocialMap38. 

To recreate:
Use the attached maps and xml. Launch a run, saving out at something like every 
5 iterations. Once you have your first disperser establish a home range, wait 
until the next backup and kill the run. Restart the run. At this point you will 
see that the map.xml is no longer updated. If you want you can checkpoint again 
at a few iterations and wait for someone else to establish a home and kill the 
run after it backs up. If you try to launch from that run you will probably get 
an error that the saved social map doesn't exist.

Original comment by acohe...@gmail.com on 27 May 2014 at 7:18

Attachments:

• ExampleBackupFolders.zip
• Ridenour.zip

[GoogleCodeExporter]

Original comment by acohe...@gmail.com on 4 Jun 2014 at 4:48

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Just realized that this is something I can work around by changing the social 
map to load myself when needed.

Changing back to medium priority.

Original comment by acohe...@gmail.com on 5 Jun 2014 at 7:19

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

IS this ok then?

Original comment by ran...@mwwb.net on 10 Aug 2014 at 8:14

[GoogleCodeExporter]

It is fixed enough to be functional. As of now the map.xml only works for 
restarting once -- after restarting it is not updated and can cause problems. 
But for restarting multiples times it is easy enough to go and change the 
map.xml to the correct map manually. 

The issue should remain open but does not require your attention at this time.

Original comment by acohe...@gmail.com on 12 Aug 2014 at 5:20