Map Recommendation using score instead of index

[sythel]

fix incoming

[sythel]

IdxRank top result shows: (Score of 700) 0,0,1,0,1,0,0,0 (Map Index 89) map 89 png shows: 3,2,0,0,0,0,0,1

[sythel]

this may be due to the weird test preferences I have been using

Seems like maps start at 0 index so we need to minus 1 from all map indexes fix incoming ^ this seems needed but causes another issue (below)

[sythel]

@elbfox is the ordering of Dams in Decisions.RData the same as the order of the dams in the application?

IdxRank top result shows: 0,0,1,0,1,0,0,0

map 88 shows: 0,0,1,0,0,0,0,1

no row in Decision has 0,0,1,0,0,0,0,1

also it seems map 62 doesn't match Decisions matrix but if the dams were out of order it could explain this

[elbfox]

Closed #136. @sythel I need to check the Decisions.RData to be sure. It should be the same, but it may be ordered from downstream to upstream.

I need to spend some time re-ordering dams anyway because we want to have them ordered from downstream to upstream. This means updating the damsdata.csv as well as the ordering of the preference elicitation tabs, if I'm understanding the problem correctly.

Tagging @samGroy in case he has some insights here.

[elbfox]

@sythel I emailed @samGroy about the Decisions.RData, because I can't tell the order of the dams based on the information I have here. I think that the dams would have to be ordered really differently in the Decisions.RData to come up with the results you shared.

Regardless, I will need to reorder the dams from downstream to upstream, so this may mean ordering them in Decisions.RData as well. Right now, I know this change entails: switching the organization in ui.R, renaming variables explicit reference to the dam name as opposed to the dam number , reordering damsdata.csv.

[elbfox]

Ok, I think I've cracked it. At some point, I reordered the decision alternatives, as well as the dams. So, I am making those changes now to be consistent with Sam's f_nrge dataset. We will still need the rules for normalizing and specific decision alternative priorities, because those problems are specific to the criteria/dam pairing (and also occur in the individual dams dataset, where the ordering of the decision alternatives/dams doesn't matter as long as it's internally consistent).

My task for the foreseeable future: re-order all dams and decision alternatives in WSM.R, ui.R, server.R to match what we gave Sam. This includes labels and the actual organization of the app, as well as the DamsData.csv. None of this should impact your rule-making, but it will give us a major headache when it comes to merging our branches.

[sythel]

max alt selecting rules lines: 1114-1196

[elbfox]

This looks like a good fix, and will work after I get done switching the dams and decision alternatives around.

[elbfox]

From Sam: "[maps] ordered by latitude I believe, so there could be some weird quirks. Also note that the map number digits are one less than the ranks (example, scenario 1 is map 0)."

[elbfox]

Ordered dams by latitude PR #139:

West Enfield Dam Medway Dam East Millinocket Dam Dolby Dam North Twin Dam Millinocket Development Millinocket Lake Dam Ripogenus Dam

Relates to issue #132 so I reopened that. Please close when that file is changed.

[elbfox]

Dams in f_nrge currently ordered by DamID (DID):

Dolby dam (DID 3395) Millinocket Lake Dam (DID 3396) Millinocket/Quakish Lake (DID 3398) North Twin (DID 3399) Ripogenus (DID3409) East Millinocket (DID 3940) Medway (DID 3942) West Enfield (DID 3969)

These need to be re-ordered by latitude as above. @sythel is this something you can do? I'm working on launching a survey today and can't get to it until tomorrow, earliest. This will probably solve our map issue, along with the knowledge that map number digits are one less than the rank (e.g., scenario is 1, map is 0).

[sythel]

Millinocket Dev == Millinocket Quakish?

[elbfox]

Yes, sorry for any confusion that may have caused. Many of the dams have more than one name, for some reason, so it's been a real trial to get those naming differences reconciled.

[sythel]

test fix in commit 6a6651d09d63becf27214f53d45e8332b62e3c38

[elbfox]

test fix in commit 6a6651d

Is this commit in the live version?

[sythel]

its live as of now

[elbfox]

Ok, there is still a disconnect between multi-dam output and mapped output after this test fix. Here are some of the files I've been using to test. EqualPrefs_forLiveSite.xlsx FishPrefs_forLiveSite.xlsx HydroPrefs_forLiveSite.xlsx

[elbfox]

Sharon tried using these and gets the error message "File is invalid:. Please verify you are uploading the correct file or try a different file."

But they all work for me, so I am not sure what is going on. EDIT this is related to #132 maybe?

[sythel]

is she uploading them as .csv files

[elbfox]

Yes

[elbfox]

She has a Mac, if that makes a difference

[sythel]

shouldn't make a difference on mac, if you can source the exact file she is using I may be able to figure it out

[elbfox]

I'll have to email them to you because I can't add them here as CSVs. They're the same files I added above but with the .csv file extension. Emailing now.

[sythel]

works ok for me @sharonklein try logging out, clearing web browser cache, logging back in then see if it persists

[elbfox]

This one doesn't work, either. Clear mismatch between maps and multi-dam results in IndividualDamOutput branch. Using EqualPrefs_forLiveSite.xlsx

[elbfox]

Also note that the map number digits are one less than the ranks (example, scenario 1 is map 0)." Did this get addressed in the test fix in commit 6a6651d ?

[sythel]

not in that commit, but is in master now

change that fixed this was old

idxScen <- c(1:995)

new

idxScen <- c(0:994)

[elbfox]

ok thank you I will continue to test.

[sythel]

hard to debug what's wrong... something with Normalization &/or Decisions is my best guess.

what would be the best way to verify that we have the dam ordering right? (ordering for Decisions and f_nrge)

sadly I won't be around tomorrow; but I will be on friday. if its still a problem it may be worth checking out the code that generated these files

[elbfox]

not in that commit, but is in master now

change that fixed this was old

idxScen <- c(1:995)

new

idxScen <- c(0:994)

Is the master version live right now? In Decisions and f_nrge, Sam confirmed that the original files are ordered like this: Dolby dam (DID 3395) Millinocket Lake Dam (DID 3396) Millinocket/Quakish Lake (DID 3398) North Twin (DID 3399) Ripogenus (DID3409) East Millinocket (DID 3940) Medway (DID 3942) West Enfield (DID 3969)

So the changes you made should have ordered them properly. The only other thing I can think of right now is that the social/cultural criteria values are driving the differences....Sam had old data in f_nrge/NormalizedMatrix (and so Decisions is impacted by that). The social/cultural criteria values we are using in DamsData.csv (e.g. Indigenous cultural traditions and lifeways, community identity, industrial historical importance, aesthetics, public health, and socio-environmental justice) are actually different from what he has in the f_nrge.RData file. I didn't think the differences were significant enough to make the results diverge this much, but I guess it's possible. We won't be able to fix this until Monday, when Sam re-runs the MOGA, unless we use the RMatlab package.

[elbfox]

max alt selecting rules lines: 1114-1196

Another idea just came to mind. This code ^ identifies priority alternatives for dams with the conditions we discussed in #133, but it looks like it's doing it after the MCDA calculation has happened? Is it layering on top of what I wrote and kept in as a placeholder?

    NormalizedMatrix[2,1,] <- 1 #This replaces fish habitat NaN at Medway
    NormalizedMatrix[1:3,3, ] <- 1#This replaces the reservoir storage NaN at West Enfield, Medway, East Mill
    NormalizedMatrix[7,2,] <- 1 #This replaces the river rec NaN at Millinocket Lake

If it the max alt selection "rules" are happening after the MCDA calculation, I can just take out the normalization code (above) I included in the NormalizationChanges branch, because it seems like the decision alternatives are being prioritized twice, maybe.

[sythel]

it looks like it's doing it after the MCDA calculation has happened? Is it layering on top of what I wrote and kept in as a placeholder?

correct

[elbfox]

Ok, removed.

[elbfox]

I have tested this over and over locally, and it looks like the idxScen is outputting the right multi-dam map based on the decision alternative codes:

0 = remove dam 1 = keep as is 2 = improve hydropower 3 = improve fish passage 4 = improve both

Like we thought, it means that the multi-dam dataset is definitely the issue right now. I'm going to close this issue and have just opened #151 with a refined definition specific to the multi-dam results not matching the individual dam results.