search

PalEON-Project / PalEON-FIA

Code to take the FIA composition, density, and biomass data and aggregate it to the PalEON grid
0 stars 2 forks source link

repeated spcd values in conversion table #3

Closed paciorek closed 7 years ago

paciorek commented 7 years ago

Should this be happening in FIA_conversion-SGD_remove_dups.csv?

Note two different rows with spcd=241, 3 for spcd=800, 2 for spcd=693

Also Doug. fir is not given a PalEON taxon, which I guess makes sense. For stat modeling, I'm throwing these out - there are only a small number of them.

Thuja occidentalis,northern white-cedar,THOC2,241,LC,Cedar/juniper,Thuja_occidentalis

Thuja spp,northern white-cedar,THOC2,241,LC,Cedar/juniper,Thuja_spp

Quercus ,oak spp. -- Deciduous,QUERC,800,SMH,Oak,Quercus_

Quercus dusomething,oak spp. -- Deciduous,QUERC,800,SMH,Oak,Quercus_dusomething

Quercus nuttalli,oak spp. -- Deciduous,QUERC,800,SMH,Oak,Quercus_nuttalli

Nyssa sylvatica,blackgum ,NYSY,693,SMH,Other hardwood,Nyssa_sylvatica

Nyssa sylvatica_2,blackgum ,NYSY,693,SMH,Other hardwood,Nyssa_sylvatica_2

paciorek commented 7 years ago

Also there are 2 trees in the FIA with spcd = 561 and 1 with spcd=934, but neither of those are in the conversion table:

statecd plt_cn tree_cn dbh statuscd spcd 1 42 222095032010661 44576076020004 23.876 1 561 2 42 222095032010661 44576079020004 25.146 1 561

statecd plt_cn tree_cn dbh statuscd spcd 1 33 247061263010661 171147320020004 25.4 1 934

jpeters7 commented 7 years ago

@SimonGoring did Sean update the conversion table? I know there was some talk about doing that before you re-ran the biomass code.
The FIA Database Description (https://paleon.geography.wisc.edu/lib/exe/fetch.php/working_groups;fiadb_user_guide_p2_6-0-2_final-opt.pdf) has spcd 561 is Ginkgo, maidenhair tree Ginkgo biloba and 934 is mountain-ash spp. Sorbus spp. I thnk I remember Ginkgo coming up in one of our phone conversations and perhaps making that be an Other hardwood? But those specific details are not in our July FIA call: https://paleon.geography.wisc.edu/doku.php/meetings;fiajuly2016

SimonGoring commented 7 years ago

@paciorek:

The duplicates are for different namings of the same general taxa within the FIA database (I am pretty sure). The duplicates are also present in:

Dietze, M. C. and Moorcroft, P. R. (2011), Tree mortality in the eastern and central United States: patterns and drivers. Global Change Biology, 17:3312--3326. doi:10.1111/j.1365-2486.2011.02477.x

Because the duplicates line up to a single set of parameters I don't think it makes a difference. I've fixed Sean's code to use a left_join (I'll add the commit ID here later), so it will pick one row and leave it at that.

Also Doug. fir is not given a PalEON taxon, which I guess makes sense.

Okay.

SimonGoring commented 7 years ago

@paciorek:

Also there are 2 trees in the FIA with spcd = 561 and 1 with spcd=934, but neither of those are in the conversion table:

So, the problem here is that spcd == 561 is Ginko, it gets mapped to Other softwood, but has an NA for the PFT . @mdietze and Moorecroft don't include it in their conversion table and there's only two in the whole FIA. It does have an entry in the Jenkins table, but I think that unless we want to classify it as a Temperate Broadleafed Deciduous tree (which, I guess it is, sort of), then it's better to exclude those two trees.

I don't get the error with the Sorbus, so maybe Sean's updated since you've run it? Or maybe my recent changes to the code (to be pushed shortly) fixed the problem.

SimonGoring commented 7 years ago

@paciorek can you let me know if you feel this is resolved when you get the chance?

paciorek commented 7 years ago

not quite: I see both black gum and sweet gum as other hardwood rather than black gum / sweet gum, which is what we have been using for the PLSS analyses.

SimonGoring commented 7 years ago

Got it. I see those & will change them.

@mdietze @crollinson, in the FIA conversion table there are also several taxa with the entry "Evergreen" in the FI conversion table (which came from Dietze & Moorcroft) that don't get recognized as PFTs. This affects Ilex opaca and Magnolia virginiana.

If you look at the appropriate lines, M. virginiana is coded as Evergreen in the table, but other Magnolia genera are coded as SMH. Is there a preference? This affects 50 trees in the FIA data.

For the Ilex opaca it's the only Ilex in the table. Thoughts on the appropriate assignments?

SimonGoring commented 7 years ago

@paciorek in version 0.4 we have black gum we have sweet gum and we have black gum/sweet gum.

Which would you prefer? Black gum/sweet gum, or should we have explicit calls to black & sweet gums based on their actual taxonomic identifications, and then aggregate them?

mdietze commented 7 years ago

@SimonGoring Magnolias are split up between which are deciduous and which are evergreen. If you have more than 1 Ilex species they should likewise be split based on phenology.

SimonGoring commented 7 years ago

Thanks @mdietze, I see that in the FIA supplement that came with Dietze & Moorehouse, so I was a bit worried aboutlumping them. The problem is that PEcAn.allometry does not recognize the Evergreen PFT that is assigned for the evergreen deciduous taxa. I was just wondering what we ought to use instead.

mdietze commented 7 years ago

The problem is that PEcAn.allometry does not recognize the Evergreen PFT that is assigned for the evergreen deciduous taxa

Could you report the code you're running that leads you to this conclusion?

Also, what do you mean by 'evergreen deciduous taxa'?

paciorek commented 7 years ago

I'd just like to mimic however we are already handling things in terms of the stage at which we end up with a black gum / sweet gum category (presumably this is the "level 3" category) and mimic how things already feed into the PLSS stats analysis.

I'm not sure what version 0.4 is -- all I'm going off of is the v0.2_SGD file in the paleon-fia repository. If there's a different conversion table file (perhaps on the wiki?) that I should be using, please point me to it.

On Fri, Oct 21, 2016 at 2:44 PM, Simon notifications@github.com wrote:

@paciorek https://github.com/paciorek in version 0.4 we have black gum we have sweet gum and we have black gum/sweet gum.

Which would you prefer? Black gum/sweet gum, or should we have explicit calls to black & sweet gums based on their actual taxonomic identifications, and then aggregate them?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PalEON-Project/PalEON-FIA/issues/3#issuecomment-255472747, or mute the thread https://github.com/notifications/unsubscribe-auth/ACYr3vOipTddscfGk1NZIEzmb7locEOuks5q2TItgaJpZM4KFrAW .

paciorek commented 7 years ago

Hi Simon, can you give me an estimated timeline on this? I'd like to start the stat model running soon so it would be helpful to have the finalized conversion table I should use.

SimonGoring commented 7 years ago

I'll work on it tomorrow to get it finished. I'm still stuck on the Pecan problem, but I need to reproduce it in a way that Mike can look at it. I should be able to figure that out then.

SimonGoring commented 7 years ago

@mdietze here's code that replicates the failure for Evergreen:

AllomAve(list(Evergreen = list(data.frame(acronym = c("ILOP", "MAVI2"), 
                                          spcd = c(591, 653))),
         components = 2,
         outdir     = "data/output/PEcAn_allom/",
         ngibbs     = 10000,
         dmin       = 17,
         dmax       = 151)

And the output I get is:

[1] "writing output to"        "data/output/PEcAn_allom/"
[[1]]
  acronym spcd
1    ILOP  591
2   MAVI2  653

[[2]]
[1] 2

[[1]]
[1] "READ.ALLOM.DATA: ** Warning no match of PFT to tally data **"

[[2]]
  acronym spcd
1    ILOP  591
2   MAVI2  653

[1] "READ.ALLOM.DATA: ** No allometric data available **"
$Evergreen
list()

Warning message:
In nu(allom$parm$Component.ID) : NAs introduced by coercion

This affects 50 ILOP & 4 MAVI2. Looking at the source data (in data/Table3_GTR-NE-319.v2.csv) it might be that neither of those taxa have allometry data entered, so that the model can't be generated. If that's the case, that we can't build an allometric model for these trees using the package, what's our option?

SimonGoring commented 7 years ago

Hi @paciorek, I believe this is all done now. The exception being that lat/long coordinates are still "fuzzed", but the lookup table exists & I maintained the dimensions of the original data set (previously some values were excised from the table).

I am closing this issue. If there are new issues can you raise them in a new issue?

@mdietze I am moving the issue with non-estimation of the Evergreens into a new issue.