GUI: single SE search

[ddalthorp]

"If only a single search was conducted, the software generates a message saying that the fix k input is ignored."

This is not quite proper. The "fix k" input MUST be used in estimating mortality and detection probability, and a message saying it is ignored is potentially misleading (but confusing at best).

[Yes, when estimating p for one search, fix k is "ignored" but it is a required parameter for estimating.]

Remove the message.

[juniperlsimonis]

what should the message say instead there then? there needs to be an indication that the fixed k value wasnt used for the SE model fitting.

[ddalthorp]

Does there?

[juniperlsimonis]

yes. otherwise a user might change the k value and expect the result of the model to change.

[ddalthorp]

The model will change...and it should. E.g., instead of the SE[i] = phat[i] 0.7^(i - 1) for fixed k = 0.7, the model with fixed k = 0.5 would be SE[i] = phat[i] 0.5^(i - 1). What doesn't change is phat.

The message is confusing because if there is only one column, a fixed k is required for estimating fatalities or detection probabilities. But the message says k is ignored?!

[juniperlsimonis]

no, the SE model doesn't change because k isn't used at all to fit the SE model when there's only one observation. if i have one observation and i fit an SE model with a fixed k at 0.7 or a fixed k at 0.2, i get the exact same output from the model

[juniperlsimonis]

in looking at the GUI now, something was changed in the output from pkm that has downstream consequences where the app is not presenting the models correctly in this instance now. pkm used to (as of v0.0.11.17) return "k not estimated" when there was only one observation, regardless of if k was fixed or not. now it only returns that if k is fixed. if k isn't fixed, it gives "k ~ 1" (which, yes, is getting translated to "k ~ constant", but that isn't correct here, because k isn't being fitted)

[ddalthorp]

Right. When a fixed k is provided, it is definitely part of the model and should be included, perhaps as "k fixed at 0.7", as it currently does if more than one obsCol is provided. When it is not provided and there is only one column, that's when we should get "k not estimated".

I'll fix.

[ddalthorp]

When there is one obsCol and kFixed is provided, summary table should give the same thing it gives when there is more than one obsCol provided (currently it gives "k not estimated" but should give "k fixed at xxx").

Where no kFixed is provided and only one obsCol is provided, the table should give "k not estimated".

The test should be on the $pOnly tag rather than the size of obsCol.

[juniperlsimonis]

the command line (and subsequently also the GUI) is currently throwing an error when you try to plot a pkm object that only has a single observation without a fixed k, but that should be able to be plotted still, right?

[ddalthorp]

Let's just throw an error for now and worry about potential pOnly figs later. We'd talked about this very issue awhile back and decided to table it for now.

BTW: Sorry for the incommunicado this morning. USGS came up with an interesting plan to shut a bunch of people out of their computer accounts...apparently it has something to do with paperwork hoops, but they skronked so many people that they are having trouble keeping up with the demand for help. I finally got access to a computer but, aside from GitHub, none of my stuff is accessible.

[juniperlsimonis]

we already have the p only figures ready, it's just a matter of re-connecting the link that was broken by the recent edits, and it will likely come as a result of the other edits that have to happen to repair the break. i just wanted to make sure that was still an appropriate figure.

[ddalthorp]

Yeah, that sounds fine. If there is no kFixed provided and no formula for k, then figs that are missing the k part are fine (although they might look a little funny).

If length(obsCol) == 1 and no kFixed is given, then pOnly <- TRUE and k formula = "k not estimated" in tables ("Model Comparison") and figs.

If length(obsCol) == 1 but a kFixed value is provided, then pOnly <- FALSE and k formula = "kFixed at 0.7 (or whatever it's fixed at)", and the model is treated like any other kFixed model. If elusive bugs pop up, one possible cause might be that the 1-dimensional array that represents carcass fates may get translated into a vector somewhere or perhaps there may be traffic signal keying on dimensions of this array rather than the value of pOnly.

[juniperlsimonis]

word. turns out the issue is pretty upstream and caused by the situation handling and traffic controlling at the top end of the pkmSet and pkmSetSize functions. i've gotten it taken care of and am tying up loose ends (like now it totally makes sense to not have the assumed k field for M when there is only a single obs but k is fixed, but we still need it when there's no fixed k and so k wasn't included in the SE model)

[ddalthorp]

awesome.

[juniperlsimonis]

this is addressed in 0.1.11 #507