Coastal Vulnerability: should each component of the exposure index be optional?

[davemfish]

Rob brought up a use-case for wanting to exclude habitat calculations from the model execution. From Slack:

The idea is to get a spatial index measure of the threat of flooding and erosion based on oceanic factors - something that is agnostic to land-side factors, though I think in my case coastal elevation would be ok to include (but it would be nice to have the option to exclude it too). I have habitat covered in a different way in my analysis.

The habitat computations are time-consuming, and so is the data preparation. So it would be nice to avoid all that if the end-user is going to disregard the habitat and recalculate the exposure index without it anyway. And basically the same argument could hold for any of the other components of the exposure index equation

As far as I can see, nothing about the math of that index (geometric mean) would break down or become inappropriate if any number of factors were included/excluded. And some are already optional. Sea-level rise is optional. And Geomorphology is optional, but forces the user to choose a constant value to apply to all shore points if no geomorphology data is provided.

So we're currently a little bit inconsistent and arbitrary about which variables are required and which are not. Thus the question, should each component of the exposure index be optional?

Any thoughts, @jesssilver @jade-md @newtpatrol?

[newtpatrol]

I don't have a strong opinion about this, haven't had an occasion to want to do it, and in some ways it seems counter to "ecosystem service" modeling to exclude the ecosystems. Meanwhile, as @davemfish says, two of the inputs are currently optional, so for consistency it seems ok to make them all optional, as long as the calculations are adjusted accordingly.

If users leave out habitats, then there would be no with-habitat exposure ranking or hab_role calculated, which again just seems counter-productive, but it does provide a level of flexibility to the model that apparently at least one person would find useful. And I suspect that most people would want to use habitats anyway.

If habitats become optional, I'd want to add text to the User Guide strongly encouraging people to use them, else there is no service being mapped.

For Rob in particular, could he just enter some bogus, quick-and-dirty habitat data, then ignore the with-habitat and hab_role results?

[jesssilver]

I don't think it makes sense to make all the inputs optional. I know geomorphology is, and SLR (which is really a scenario element), but I think at some point if you pick and choose the components you want to include you lose the 'well-rounded'-ness of the index in capturing different components of exposure. You might include Katie in this conversation, she still has time to work with NatCap and will have strong opinions. I also don't think the habitats should be optional *but *if there was one additional element to make optional - I would choose to make that one optional. B/c there's precedent for the original index with the components that are included (wind, waves, elevation, etc), and habitats are the InVEST add-on. I think ultimately I would ask one of the original developers of this model - in this case probably Katie is the easiest to access and get her take. I think if Rob is just interested in the forcing conditions, for now he can put in dummy habitats and just recompute the EI without that variable. J.

…

On Mon, Jun 19, 2023 at 2:52 PM newtpatrol ***@***.***> wrote: I don't have a strong opinion about this, haven't had an occasion to want to do it, and in some ways it seems counter to "ecosystem service" modeling to exclude the ecosystems. Meanwhile, as @davemfish <https://github.com/davemfish> says, two of the inputs are currently optional, so for consistency it seems ok to make them all optional, as long as the calculations are adjusted accordingly. If users leave out habitats, then there would be no with-habitat exposure ranking or hab_role calculated, which again just seems counter-productive, but it does provide a level of flexibility to the model that apparently at least one person would find useful. And I suspect that most people would want to use habitats anyway. If habitats become optional, I'd want to add text to the User Guide strongly encouraging people to use them, else there is no service being mapped. For Rob in particular, could he just enter some bogus, quick-and-dirty habitat data, then ignore the with-habitat and hab_role results? — Reply to this email directly, view it on GitHub <#1335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEX6RCRJJT2JW4CHSUAR27TXMDCYHANCNFSM6AAAAAAZMGNTRA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Jess Silver The Natural Capital Project Stanford University

[davemfish]

Cool, thanks for your inputs. I think Rob has a workable solution already, along the lines of your suggestions. I posed this question to see if anyone else has ever found themselves wanting this functionality. I have wanted to exclude habitat myself, but only for purposes of more quickly getting results for debugging other parts of the model.

This isn't something we need to pursue unless there is demand for it. But I do like the idea of making our software more useful by being a little less prescriptive about how people should use it. CV is probably one of the few tools out there that do all those wind, wave, & surge calculations, and plot points along a coastline for you, etc. So in general I'm all for people using that functionality even if they don't have a specific "ecosystem service" style research question.

One compromise could be to keep habitats required in the user-interface, forcing people to use the model how it was designed, but allow Python users to call the model's execute function with or without a habitat input, thus making it optional for those users. I'm not sure there's a precedent for that, but could be worth considering.

[jesssilver]

Yes - to you question I definitely run the model without habitats when I'm trying to make sure the other components are running well. J.

…

On Tue, Jun 20, 2023 at 6:35 AM Dave Fisher ***@***.***> wrote: Cool, thanks for your inputs. I think Rob has a workable solution already, along the lines of your suggestions. I posed this question to see if anyone else has ever found themselves wanting this functionality. I have wanted to exclude habitat myself, but only for purposes of more quickly getting results for debugging other parts of the model. This isn't something we need to pursue unless there is demand for it. But I do like the idea of making our software more useful by being a little less prescriptive about how people should use it. CV is probably one of the few tools out there that do all those wind, wave, & surge calculations, and plot points along a coastline for you, etc. So in general I'm all for people using that functionality even if they don't have a specific "ecosystem service" style research question. One compromise could be to keep habitats required in the user-interface, forcing people to use the model how it was designed, but allow Python users to call the model's execute function with or without a habitat input, thus making it optional for those users. I'm not sure there's a precedent for that, but could be worth considering. — Reply to this email directly, view it on GitHub <#1335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEX6RCTMPVHFD3FPXXPH7YLXMGRJNANCNFSM6AAAAAAZMGNTRA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Jess Silver The Natural Capital Project Stanford University

[davemfish]

So it sounds like a few of us would see benefits from the habitats being optional -- making it quicker & easier to run without habitats. And we're probably not the only ones.

But I hear that there is a larger concern/question about whether or not we should facilitate use of our models in ways they were not intended.

[rmgriffin]

Great feedback @jesssilver and @newtpatrol - the concern about needing to reiterate to users how the model should run, even if features are optional, crossed my mind as well. I figure an eventual backstop filter for a half-baked vulnerability index would be peer-review, if folks were trying to run this without the expertise to conceptually understand the basis for the index. That said, there's probably some additional text that would be needed to indicate the core elements in the user's guide.

Most of my use of invest models seems to run afoul of their original design intent, so I wholeheartedly support @davemfish in the quest to make InVEST less prescriptive. But I don't have the task of supporting this model or the user's guide, so the existence of a straightforward workaround works for me, and presumably anyone else that ends up in this position.

[davemfish]

Most of my use of invest models seems to run afoul of their original design intent,

And isn't this so often the case for many of us? Where we get into the details of a project and reach the limitations of invest and then need to do some other analysis before/after in order to accomplish our goal.

If invest models had a slightly more modular structure, that could make them more useful as well. Again I'm mostly thinking in terms of the Python API, but what if instead of just one user-facing execute function that does everything A-Z, there were a few user-facing functions that do subcomponents of the model. Internally, they could be pieced together to build the complete execute function. But they could also be used individually as building blocks for other customized workflows.

To some extent this is how the model is structured now. But in general the functions that execute is composed of are very much designed only for that purpose, and would be cumbersome to use in a more stand-alone way.

[jesssilver]

Yeah, I think this would be cool... (the subcomponents that could be individually executable). And it could even be architected in such a way that it might promote some model troubleshooting/critical assessment to make sure the pieces are working correctly. That model is pretty complicated and if you never look at any of the underlying pieces there's a lot of possibility for things to be wrong and one doesn't know. I'm thinking here about the fetch calculations wind & wave etc.

…

On Wed, Jun 21, 2023 at 7:18 AM Dave Fisher ***@***.***> wrote: Most of my use of invest models seems to run afoul of their original design intent, And isn't this so often the case for many of us? Where we get into the details of a project and reach the limitations of invest and then need to do some other analysis before/after in order to accomplish our goal. If invest models had a slightly more modular structure, that could make them more useful as well. Again I'm mostly thinking in terms of the Python API, but what if instead of just one user-facing execute function that does everything A-Z, there were a few user-facing functions that do subcomponents of the model. Internally, they could be pieced together to build the complete execute function. But they could also be used individually as building blocks for other customized workflows. To some extent this is how the model is structured now. But in general the functions that execute is composed of are very much designed only for that purpose, and would be cumbersome to use in a more stand-alone way. — Reply to this email directly, view it on GitHub <#1335 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEX6RCWDZUPVWYF55ODU45DXML7EDANCNFSM6AAAAAAZMGNTRA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Jess Silver The Natural Capital Project Stanford University