{ "access": { "embargo": { "active": false, "reason": null }, "files": "public", "record": "public", "status": "open" }, "created": "2019-11-18T02:39:31.403065+00:00", "custom_fields": {}, "deletion_status": { "is_deleted": false, "status": "P" }, "files": { "count": 1, "enabled": true, "entries": { "TPCA_source_and_matchups-1.0.zip": { "checksum": "md5:41abef57a64ffd70daeec1af8fb5a08f", "ext": "zip", "id": "87cabd00-fde3-42a3-9da9-1c599552ee68", "key": "TPCA_source_and_matchups-1.0.zip", "metadata": null, "mimetype": "application/zip", "size": 219177 } }, "order": [], "total_bytes": 219177 }, "id": "3538213", "is_draft": false, "is_published": true, "links": { "access": "https://zenodo.org/api/records/3538213/access", "access_links": "https://zenodo.org/api/records/3538213/access/links", "access_request": "https://zenodo.org/api/records/3538213/access/request", "access_users": "https://zenodo.org/api/records/3538213/access/users", "archive": "https://zenodo.org/api/records/3538213/files-archive", "archive_media": "https://zenodo.org/api/records/3538213/media-files-archive", "communities": "https://zenodo.org/api/records/3538213/communities", "communities-suggestions": "https://zenodo.org/api/records/3538213/communities-suggestions", "doi": "https://doi.org/10.5281/zenodo.3538213", "draft": "https://zenodo.org/api/records/3538213/draft", "files": "https://zenodo.org/api/records/3538213/files", "latest": "https://zenodo.org/api/records/3538213/versions/latest", "latest_html": "https://zenodo.org/records/3538213/latest", "media_files": "https://zenodo.org/api/records/3538213/media-files", "parent": "https://zenodo.org/api/records/3538212", "parent_doi": "https://zenodo.org/doi/10.5281/zenodo.3538212", "parent_html": "https://zenodo.org/records/3538212", "requests": "https://zenodo.org/api/records/3538213/requests", "reserve_doi": "https://zenodo.org/api/records/3538213/draft/pids/doi", "self": "https://zenodo.org/api/records/3538213", "self_doi": "https://zenodo.org/doi/10.5281/zenodo.3538213", "self_html": "https://zenodo.org/records/3538213", "self_iiif_manifest": "https://zenodo.org/api/iiif/record:3538213/manifest", "self_iiif_sequence": "https://zenodo.org/api/iiif/record:3538213/sequence/default", "versions": "https://zenodo.org/api/records/3538213/versions" }, "media_files": { "count": 0, "enabled": false, "entries": {}, "order": [], "total_bytes": 0 }, "metadata": { "creators": [ { "affiliations": [ { "name": "University of Tasmania" } ], "person_or_org": { "family_name": "Nicholas", "given_name": "Pittman", "identifiers": [ { "identifier": "0000-0002-4632-7223", "scheme": "orcid" } ], "name": "Nicholas, Pittman", "type": "personal" } } ], "description": "
The Tropical Pacific Chlorophyll Algorithm (TPCA): source code and matchup data is a supplement to Pittman et al., 2019 (2019JC015498).
\n\nThe matchup dataset is coincident in situ and satellite chlorophyll observations for the tropical Pacific (10°N to 10°S and 150°E to 90°W). The matchups are defined as any coincident matchup within ±2 days and ±1 pixel (~15km). Matchup sets are provided for the satellite sensors SeaWiFS, MODIS-Aqua and MERIS.
\n\nThe source code provided includes algorithms for producing the TPCA algorithm from Level 3 Mapped > Daily > 9km RRs data obtained from https://oceandata.sci.gsfc.nasa.gov/. Example scripts are provided to produce the TPCA from:
\n1) directly downloading data from the oceandata portal
\n2) from the matchup database. A number of statistical methods are provided to assess performance.
Matchup data was obtained from several sources:
\n1) Tropical Atmosphere Ocean (TAO) mooring maintenance cruises. This is the same dataset used by Strutton et al. (2008), provided by Francisco Chavez, Monterey Bay Aquarium Research Institute.
\n2) Valente et al. (2016; https://doi.org/10.1594/PANGAEA.854832)
\n3) Word Ocean Database 2018 (WOD; Boyer et al., 2018; https://www.nodc.noaa.gov/OC5/WOD/pr_wod.html)
Contents
\n\nMatchup details
\n\nSatellite to in situ matchup files as used in Pittman et al., 2019 [1] have been openly provided for as per the Journal of Geophysical Research: Oceans guidelines.
\n\tThree files are provided. Each file is a *.csv matchup database for one of the three sensors analysed; SeaWiFS, MODIS-Aqua and MERIS.
\n\tChlor_a and relevant Rrs data for the three sensors was downloaded from the NASA ocean color portal: https://oceandata.sci.gsfc.nasa.gov/
\n\tMonthly MEI (Multivariate ENSO Index) has matched from: https://www.esrl.noaa.gov/psd/enso/mei.old/
\n\tMore details about the matchup process and sensor details / sources. R,eprocessing versions are 2018.0 for SeaWiFS and MODIS-Aqua, and 2012.1 for MERIS.
\n\tIn situ fluorometric data has been compiled from three unique sources [4,5,6]
\n\tEach sensor has a different number of matchups due to time period in orbit, different orbits, cloud cover and quality control.
\n\tThese matchup files are those used in [1]; 2 day radius and 1 pixel. This results in a total of 5 days (day, day, observation, day, day) and a grid of 9 pixels, with the observation located in the centre pixel. The matchups provided are the mean of these 45 pixels. For example in space:
\n\tSat Sat Sat
\n\nSat Ob Sat
\n\nSat Sat Sat
\n\nMatchup database
\n\nThe *.csv files contain 28 fields including:
\n\nA description of the matchup databse is available from the github repository: https://github.com/nicpittman/TPCA_source_and_matchups , release v1.0.
", "languages": [ { "id": "eng", "title": { "en": "English" } } ], "publication_date": "2019-11-18", "publisher": "Zenodo", "references": [ { "reference": "Pittman, N. A., Strutton, P.G., Johnson, R., Matear R., Chavez, F.P. (2019). An assessment and improvement of tropical Pacific Ocean Color algorithms. Submitted to Journal of Geophysical Research: Oceans" }, { "reference": "Hu, C., Lee, Z., and Franz, B. (2012). Chlorophyll a algorithms for oligotrophic oceans: A novel approach based on three-band reflectance difference. Journal of Geophysical Research: Oceans\u00a0117." }, { "reference": "O'Reilly, J.E., Maritorena, S., Mitchell, B.G., Siegel, D.A., Carder, K.L., Garver, S.A., Kahru, M., and McClain, C. (1998). Ocean color chlorophyll algorithms for SeaWiFS. Journal of Geophysical Research: Oceans\u00a0103, 24937\u201324953." }, { "reference": "Boyer, T.P., Baranova, O.K., Coleman, C., Garcia, H.E., Grodsky, A., Locarnini, R.A., Mishonov, A.V., Paver, C.R., Reagan, J.R., Seidov, D., et al. World Ocean Database 2018. A. V. Mishonov, Technical Editor, NOAA Atlas NESDIS 87." }, { "reference": "Strutton, P.G., Evans, W., and Chavez, F.P. (2008). Equatorial Pacific chemical and biological variability, 1997\u20132003. Global Biogeochemical Cycles 22." }, { "reference": "Valente, A., Sathyendranath, S., Brotas, V., Groom, S., Grant, M., Taberner, M., Antoine, D., Arnone, R., Balch, W.M., Barker, K., et al. (2016). A compilation of global bio-optical in situ data for ocean-colour satellite applications. Earth System Science Data 18." } ], "related_identifiers": [ { "identifier": "https://github.com/nicpittman/TPCA_source_and_matchups/tree/1.0", "relation_type": { "id": "cites", "title": { "de": "Zitiert", "en": "Cites" } }, "resource_type": { "id": "software", "title": { "de": "Software", "en": "Software" } }, "scheme": "url" } ], "resource_type": { "id": "software", "title": { "de": "Software", "en": "Software" } }, "rights": [ { "description": { "en": "A permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code." }, "id": "apache-2.0", "props": { "scheme": "spdx", "url": "http://www.apache.org/licenses/LICENSE-2.0" }, "title": { "en": "Apache License 2.0" } } ], "subjects": [ { "subject": "Regional ocean color algorithm" }, { "subject": "biological oceanography" }, { "subject": "Equatorial Pacific" }, { "subject": "Chlorophyll Algorithm" }, { "subject": "SeaWiFS" }, { "subject": "MODIS-Aqua" }, { "subject": "python3" } ], "title": "Tropical Pacific Chlorophyll Algorithm (TPCA): Source code and matchups v1.0 Primary release for Pittman et al., 2019", "version": "v1.0" }, "parent": { "access": { "owned_by": { "user": 52772 } }, "communities": { "default": "412b0d7e-da92-47a4-8616-223835adcc29", "entries": [ { "access": { "member_policy": "open", "members_visibility": "public", "record_policy": "open", "review_policy": "open", "visibility": "public" }, "children": { "allow": false }, "created": "2018-09-23T07:20:36.403658+00:00", "custom_fields": {}, "deletion_status": { "is_deleted": false, "status": "P" }, "id": "412b0d7e-da92-47a4-8616-223835adcc29", "links": {}, "metadata": { "curation_policy": "The CLEX Code Collection accepts any code contribution from CLEX researchers, students and collaborators which is relevant to climate science.
\r\n\r\nWe will accept only code which is licensed with an open access license. The aim of this collection is to share code for the community benefit, which is also in line with ARC open access recommendations. However, it is possible to apply an embargo period to the record or in exceptional circumstances having closed access.
\r\n\r\nWe can accept code already registered in another repository as long as this does not break the other repository rules. In such cases we will use the other repository DOI and where applicable the original metadata records as the main reference.
\r\n\r\nOur definition of code includes:
\r\n\r\na single source code,
\r\n\ta collection of code files, both organised as a module or not,
\r\n\ta jupyter notebook or workflow script detailing a data analysis or pre-processing workflow,
\r\n\tmodel configuration files or other code associated with running models as long as they are well described and fit to be shared, and
\r\n\tany code associated with a journal publication
\r\n\tWe will not accept:
\r\n\r\nCode which is a variation of an existing code but does not add substantial value to the original (see also authorship policy)
\r\n\tCode which is poorly described, we do not run quality checks on the code itself but your code has to have reasonable documentation such that is possible for someone else to reuse it. (see Guidance for contributors)
\r\n\tIt is hard to describe here all the possible variations, if you are in doubt as to whether your code is acceptable, please contact us and we can review your case.
\r\n\r\nWe are using Zenodo as a platform so it is also important that your submission satisfies the Zenodo policies.
\r\n", "page": "The aim of this community is to collect the code and code documentation produced by the Centre of Excellence for Climate Extremes (CLEX). CLEX is a major initiative funded by the Australian Research Council (ARC). This Centre of Excellence is an international research consortium of five Australian universities and a network of outstanding national and international partner organisations.
\r\n\r\nClick on 'read more' to know how to use and contribute to this collection, use clexcodecollection<at>gmail.com to contact us
\r\n\r\nTable of contents
\r\n\r\n\r\n\r\n
Anyone! All records available on the CLEX Code Collection are required to have an open access license.
\r\n\r\n\r\n\r\n
If you have found a record in the CLEX Code Collection that you would like to use, please read the record description and download the code from the source. Where applicable, check that you have access to any required datasets and installed relevant software packages before executing the code.
\r\n\r\nWe request that any published research stemming from a record within the CLEX Code Collection appropriately cite the source as provided in the record description.
\r\n\r\n\r\n\r\n
The codes have not been tested by the curators of the collection. For basic troubleshooting the curation team encourages end users to email the main contact provided in the record.
\r\n\r\nIn instances where you found a scientific error in the code and the author is not responding within a fortnight, please contact the curation team at: clexcodecollection<at>gmail.com.
\r\n\r\nFor further clarification on how issues are resolved please consult the issues workflow.
\r\n\r\n\r\n\r\n
Remember that authors are not required to answer all queries about their code, and therefore responses may not be immediate. Prior to contacting authors, it is recommended that end users search possible solutions on platforms like Stack Overflow. If you have not found an answer to your problem and need to contact the author directly, check if your question falls within the type of questions authors have indicated they will support in the record description and/or the source webpage of the record where applicable.
\r\n\r\nFinally, check guidelines on how to ask a good question from Stack Overflow and ResearchGate. As a general rule, the clearer and more precise your question is, the better an answer you will receive.
\r\n\r\n\r\n\r\n
While the curation team endeavours to maintain the usability and scientific validity of all records that are part of the CLEX Code Collection, we accept no liability for the damages arising from the use of the codes.
\r\n\r\nThe curation team will regularly maintain the collection and update the title and description of records in instances where there are scientific errors as per the procedures described in the Retention and Retraction Policy.
\r\n\r\nIt is the end user's responsibility to check whether the code is suitable for their intended use and if there are updates to the record on the CLEX Code Collection that they are using.
\r\n\r\n\r\n\r\n
\r\n\r\n
The curation team accepts “any code” contribution from CLEX researchers, students and collaborators which is relevant to climate science.
\r\n\r\nAll authors must comply with all applicable laws and not be intentionally malicious. Codes should adhere to the Authorship Policy and not violate any prior license agreement.
\r\n\r\nShould the code contain or require any sensitive data, the authors must comply with the disclosure conditions of any prior ethics agreement.
\r\n\r\nAuthors are encouraged to record their code under version control software before contribution (eg. on Github, Bitbucket, Gitlab). Preferably, the authors should then create their own record on Zenodo under their own account (an ORCID can be used to create a Zenodo account). Zenodo can connect with, for example, Github for easy creation of the record from the information on a Github repository. Only the owner of the original Zenodo record is allowed to amend the record.
\r\n\r\n\r\n\r\n
All code submissions will require a description that is adequate for an end user unfamiliar with the code to download, compile and run. Therefore, mandatory content includes:
\r\n\r\nBrief description of:
\r\n\r\n\tthe purpose and scope
\r\n\t\tSoftware requirements (where applicable)
\r\n\t\tData requirements (where applicable) - particularly if any intermediate data processing is required before using the tool
\r\n\t\tAn example of how to execute the code
\r\n\t\tIdeally authors should also include information on what level of support they are willing to provide to end users. This may include bug reporting, improvements, documentation updates and repurposing code for other datasets.
\r\n\t\tValid contact details for end users and the curation team to ask follow-up questions. These contact details should be kept up-to-date.
\r\n\tIdeally the authors should also provide their ORCID for tracking citations of the contribution
\r\n\tKeywords for searchability. We provide a minimum keyword requirements list.
\r\n\tLicense agreement
\r\n\tA code can have several authors. All authors should have made a significant contribution to the code. A person is not an author if their contribution only constitutes of:
\r\n\r\nsupervision
\r\n\tthe provision of funding, data, materials, infrastructure or access to equipment
\r\n\tthe provision of routine technical support, technical advice or technical assistance
\r\n\tproviding feedback or a review of the code
\r\n\t\r\n\r\n
We created a step-by-step guide and a checklist to show how to upload a record.
\r\n\r\n\r\n\r\n
All submissions will be reviewed to ensure documentation requirements are met. A workflow on the review process is available.
\r\n\r\nOnce all requirements have been met, the curator will either link the existing Zenodo record to the CLEX Code Collection or create a new Zenodo record.
\r\n
Authors to the CLEX Code Collection agree to be contactable by the curating team and end users whenever issues or bugs are detected. Ideally, authors should respond to queries in a timely manner. We detailed how issues will be dealt with in this workflow.
\r\n\r\nIssues that impact the scientific validity of the code will have a warning flag added to the Zenodo record to ensure that end users are aware. Ideally these should be resolved within six months of identification. If the issue remains unresolved the record will be retracted from the CLEX Code Collection only, and not on the host repository. Refer to the Retraction policy for more information.
\r\n\r\nAuthors are encouraged, but are not required to answer questions that end users may have regarding their code. Authors must keep their contact details up to date in the Zenodo record. Authors must provide their preferred contact method for queries about the code, which may include an email address or persistent researcher ID (e.g., ORCID) or link to a repository in another platform (e.g., Github).
\r\n\r\nAuthors must also specify if they are able/willing to provide limited (e.g., bug reporting) or full assistance (e.g., adapting software/scripts to a different field than was initially intended).
\r\n\r\n\r\n\r\n
Authors may choose to further amend the code on the host repository. For published records, code changes will require a new version to be recorded in Zenodo. The contribution will be reviewed again. In some exceptional cases, the author might be required to create an entire new record. The curators of the CLEX Code Collection will guide the authors on the process if this exception applies
\r\n\r\nIf there are frequent end user queries on how to get the code to work, the curator will seek an amendment of the record description from the author.
\r\n\r\nShould end users make amendments to the code, they are encouraged to collaborate with the authors.
\r\n\r\n\r\n\r\n\r\n\r\n
\r\n\r\n
You can only submit a code for which you are an author.
\r\n\r\nAn author is a person who has created or modified a code in a substantial way, either as an individual or part of a group effort.
\r\n\r\nA code can have several co-authors. All co-authors should have made a significant contribution to the code. Each author needs to give their agreement to be listed as an author. In addition, if some co-authors are not from CLEX, they should give their agreement for the code to be listed under the CLEX Code Collection.
\r\n\r\nIt is possible to define contributors in the CLEX Code Collection, some of the potential contributor roles are:
\r\n\r\nReviewer
\r\n\r\n\tTo qualify, the review needs to be a substantial effort, which results in improvements/changes being applied to the code.
\r\n\t\tCurator
\r\n\r\n\tPerson tasked with reviewing, enhancing, cleaning, or standardizing the code and the associated metadata in a way that goes beyond the ordinary curation of the code collection
\r\n\t\tContent-expert
\r\n\r\n\tSomeone who contributed mainly by providing advice/review on the scientific validity of the code
\r\n\t\tThese definitions are based on the authorship and co-authorship policy on the Australian Code for the Responsible Conduct of Research 2018.
\r\n\r\nYou can only submit a modified code if the modifications add value to the code. For example, the new code may improve efficiency or the ease of use or include scientific changes.
\r\n\r\nWhen submitting a modified code, the authors are responsible to ensure the licensing and ethical terms of the original code allow for that submission.
\r\n\r\nExamples of code where you are an author and therefore may submit the code to the CLEX Code Collection:
\r\n\r\nYou created a new analysis code based on widely used modules/packages/libraries of the software language of your code.
\r\n\tYou modified someone else’s analysis code:
\r\n\r\n\tBy rewriting a code to a different language (e.g from matlab to Python)
\r\n\t\tBy updating an old code to a new version of the software language or software packages requiring significant changes
\r\n\t\tBy adding extra analysis steps and complexity
\r\n\t\tBy updating an existing code to run on a new set of data that requires additional steps to process the same analysis.
\r\n\t\t\r\n\r\n
Examples of code where you are not an author and therefore do not meet requirements as a new record in the CLEX Code Collection:
\r\n\r\n\r\n\r\n
Changes only affecting paths to the data. E.g. to use a code on a different server or with a different set of data.
\r\n\tChanges to underlying packages that require to change only a few function arguments.
\r\n\t\r\n\r\n
CLEX will actively maintain the Code Collection and retain your records for its lifetime (end of 2024). After that CLEX cannot guarantee that the curation of the Collection will continue. The Code Collection will continue to exist on Zenodo and the records will be retained provided they do not violate the Zenodo policies. The retention time for Zenodo is the lifetime of their host laboratory CERN, currently funded for the next 20 years. For more information or updates check the Zenodo policies page.
\r\n\r\nRecords will be immediately removed, if the curator finds they are in breach of the authorship policies.
\r\n\tRecords will be removed should scientific errors in the code be raised and no reasonable attempt is made on the owner's side to review and amend the issues. The procedure and timeframe for this are described in the Amendment procedure section below.
\r\n\tIf the software/package versions are outdated and no longer supported and the code cannot be executed without revision, the contact author will be advised and opportunities provided to update the code to more recent software versions. If this cannot be done, code will be marked as obsolete.
\r\n\t\r\n\r\n
In case of significant scientific errors:
\r\n\r\nThe Collection curator will warn the contact author and establish a course of action to amend the erroneous code.
\r\n\tThe curator will then put a warning on the record stating the nature of the issue and the potential timeframe for resolution.
\r\n\tIf the record is amended, a new version will be published and the older one retained for provenance reasons. The title of the erroneous version will be altered to notify clearly that it is retracted, and a summary of the issue and its resolution will also be added to the description.
\r\n\tIf no amendment/correction is made, the record will be removed from the collection. Note that any retraction will only remove the record from the collection and not the original source (e.g. that may be on github, bitbucket, the author’s own Zenodo account etc.)
\r\n\tWhere the curation team has ownership of the original Zenodo code, we will alter the title and description to reflect the retraction state.
\r\n\t\r\n\r\n
In case of obsolete code:
\r\n\r\nThe Collection curator will warn the contact author and establish a course of action to update the code.
\r\n\tThe curator will then put a warning on the record stating that the code is deemed obsolete and the reasons for this.
\r\n\tIf the author agrees to updating the code, the warning should also display the likely timeframe of the update. If the record is amended, then a new version will be published and any warning on previous versions removed
\r\n\tIf the author decides not to update the code, it will be marked as obsolete. A notice explaining why the code is deemed obsolete and the reasons it will not be updated will be added to the description.
\r\n\t