gadgetfleet() / mfdb_group() when fleets operate on only 1 of multiple areas

[pamelajwoods]

Hi,
I have a 2 area model ('1' and '2'), with 2 fleets, the first of which only operates on area '1' and the second of which operates on area '2'. I found that when using gadgetfleet %>% gadget_update(...data=landings.1) to update the first fleet, for example, it works fine to have the landings data frame defined by structure(..., area_group = mfdb_group('1'=1)), where all landings within the data frame come from area 1. However, if the second fleet is updated with a data frame defined by structure(..., area_group = mfdb_group('2'=2)), and all landings come from area 2, then the fleet data file does not write properly (all areas written as NA instead of 2) and 'livesonareas' within the fleet file is blank.

It works just fine however for both cases when structure(..., area_group = mfdb_group('1' = 1,'2' = 2)) is used: both the data are written correctly and 'livesonareas' is written with only the area that is found within the data file (not both as find in the data frame attributes). This is not an urgent problem - just a quirk I found that was not intuitive.

Thanks!
Pamela

[lentinj]

I think I'd need to see more of your code to understand what's going on properly, if that's easy to do?

However, I suspect the problem is in gadget_fleet_component in Rgadget, which tries to give each area a unique number and return that in the fleet file. So in the case of mfdb_group('1' = 1,'2' = 2), it numbers '1' as 1, '2' as 2 and everything happens to work. In the case of mfdb_group('2'=2), it will number area '2' as 1 (it's the first area in the list), and hilarity is probably ensuing because of this. In your case this renumbering isn't necessary and possibly this is something it should detect.

According to my comments, this is done in the first place because there's no aggregation file we can write the area names to. This could be a cleaner way to solve the problem, but more intrusive.

[pamelajwoods]

Thanks for the detailed response! Ok we will keep it in mind in updating Rgadget. If necessary I'll send more details next time. Best wishes, Pamela

…

On Tue, Oct 30, 2018 at 11:56 AM Jamie Lentin ***@***.***> wrote: I think I'd need to see more of your code to understand what's going on properly, if that's easy to do? However, I suspect the problem is in gadget_fleet_component in Rgadget, which tries to give each area a unique number and return that in the fleet file. So in the case of mfdb_group('1' = 1,'2' = 2), it numbers '1' as 1, '2' as 2 and everything happens to work. In the case of mfdb_group('2'=2), it will number area 2 as 1 (it's the first area in the list), and hilarity is probably ensuing because of this. In your case this renumbering isn't necessary and possibly this is something it should detect. According to my comments, this is done in the first place because there's no aggregation file we can write the area names to. This could be a cleaner way to solve the problem, but more intrusive. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad0u2l7vGKRTuLd9Tpd_dPOqa0vYtpR7ks5uqD5igaJpZM4XjuXc> .