Pecan: ED2의 Write.configs 오류

Doh, 방금 Fluxnet을 사용하여 Sipnet을 사용한 최근 성공적인 실행을 되돌아보았고 met 프로세스 XML에도 met.start/end 날짜가 없지만 정상적으로 실행되었으므로 ed 래퍼가 어떻게 되는지 확인해야 할 수도 있습니다. pecan.CHECKED 버전도 아닙니다.....

@ashiklom 최근에 ED2를 많이 사용했기 때문에 여기에만 태그를 지정

의심되는 대로 다시 실행하고 다음을 입력합니다.

  <run>
    <site>
      <id>676</id>
      <met.start>1999-01-01</met.start>
      <met.end>2008-12-31</met.end>
    </site>
    <inputs>
      <css>
        <id>2000000005</id>
      </css>

원래 오류를 피했습니다. 그러나 처음부터 만남을 생성하는 경우 최종 시작/종료 날짜가 무엇인지 미리 알고 싶지 않습니다. 적절한 시간에 삽입할 수 있을 만큼 똑똑해야 합니다.

AFAICT, met.start 및 met.end 는 웹 인터페이스 에서만 설정됩니다. 자동으로 설정하는 R 코드는 없습니다.

웹 인터페이스가 하는 모든 숨겨진 것들에 대한 나의 호언장담을 하십시오...

그러나 처음부터 만남을 생성하는 경우 최종 시작/종료 날짜가 무엇인지 미리 알고 싶지 않습니다. 적절한 시간에 삽입할 수 있을 만큼 똑똑해야 합니다.

100% 동의합니다. 워크플로의 기본 가정은 사용자가 특별히 지정하지 않는 한 met.start / met.end 가 실행과 동일하다는 것입니다.

설정해야 하는 _where_에 관해서는 ED가 충족된 사이클링 유틸리티(또는 실제로 met.start / met.end 태그를 사용하는 것)를 갖는 고유한 ED에 따라 다릅니다.

_개인적으로_ 제 생각에는 ED의 만남 주기를 전혀 사용하지 않는 것이 좋을 것 같습니다. 주기된 만남으로 모델을 실행하려는 경우 PEcAn 측에서 명시적으로 만난 모임을 생성하여 다른 모임과 함께 사용할 수 있도록 하는 것이 좋습니다. 모델들도.

웹 인터페이스가 하는 모든 숨겨진 것들에 대한 나의 호언장담을 하십시오...

@ashiklom 웹 인터페이스의 역할은 pecan.xml 설정을 돕는 것입니다. 그런 의미에서 모든 것은 디자인에 의해 '숨겨진' 것입니다. 웹 인터페이스를 사용하여 pecan.xml을 설정하지 않는 경우 태그를 포함하는 것을 잊어버리면 웹 인터페이스 오류가 발생하는 이유는 무엇입니까?

처음부터 만남을 생성하는 경우 최종 시작/종료 날짜가 무엇인지 미리 알고 싶지 않습니다.

나는 따르지 않는다. 처리가 충족되면 처리하려는 날짜를 시스템에 알려야 합니다. 왜 그걸 미리 알아야 하지 않겠습니까?

으아아아아아앙!!! 웹이 다시 공격합니다! 그게 다야!

지금 수행 할 수 있습니다 무엇인지, 이에 따라 1)가 필요합니다 ED2 같은 모델 met.start / met.end를 삽입하는 코드에 넣어이다; 2) CF_gapfill(?) 소스의 모든 모델에 대해 met 프로세스를 재활용하는 옵션을 귀하가 말한 대로 생성할 수 있습니다. 예를 들어, 2000-2008이 있고 2000-2012를 실행하려는 경우 모델별 충족 레코드에 대해 생성할 수 있습니다. ~에

@mdietze 문제는 새로운 충족을 요청하는 모델 실행을 시작할 때 기본적으로 모델 실행 시작/종료를 설정하여 충족된 시작/종료 날짜를 설정하는 것입니다. 이와 같이 write.configs에 도달하면 WC에서 충돌하는 대신 XML 태그에 삽입해야 하지 않을까요? 즉, 사용자가 충족된 드라이버를 생성하기 전에 처음에 충족된 날짜와 모델 날짜를 입력해야 합니까? 괜찮은 것 같지만 불필요한 것 같다

이를 위해 데이터베이스에서 만난 ID를 가리키면 pecan이 해당 ID를 조회하고 당신을 위해 만난 날짜도 삽입할 수 없어야 합니까?

공정하게 말해서, 저는 가끔 PEcAn에서 작업을 수행하는 이유를 이해하기 어려울 때도 있고 일부 정보가 올 수 있는 경우에도 모든 설정/옵션에 대해 매우 구체적이어야 하는 경우가 있습니다. 데이터베이스에서.

• 웹 인터페이스는 실행 날짜와 만난 날짜가 동일하다고 가정하고 동일하게 설정하지만 고급 편집에서 해당 기본값을 변경할 수 있습니다. 고급 편집을 유효하게 사용하는 것으로 가정을 깨는 실행을 설정하는 것을 고려합니다.
• 사용자의 인식 없이 만난 사이클링은 매우 바람직하지 않은 기능이기 때문에 DB의 만난 레코드가 기본(만난 시간 = 실행 시간)을 변경하는 것이 합리적이지 않다고 생각합니다. 2001년을 두 번째로 실행한 다음 2018년 데이터에 대해 유효성을 검사하려고 합니까?)
• met.start/met.end가 수동으로 또는 웹에서 설정되지 않은 경우 PEcAn.settings::prepare.settings 동안 실행 날짜로 설정해야 한다는 건전한 주장이 있다고 생각합니다.
• PEcAn 내에서 만난 순환을 추가하려는 경우 PalEON에서 심볼릭 링크를 생성하여 의사 '주기'가 만나는 일부 코드가 있습니다(예: 650.nc는 1850.nc, 651.nc -> 1851.nc를 가리킴 등). ). 데이터베이스가 과거에 실제로 데이터가 아닌 파일을 가지고 있다고 생각하게 하는 것이 위험하고 업데이트를 엉망으로 만들 수도 있기 때문에 메인라인에 포함하지 않았습니다. 1978.nc -> 2017.nc, 프로세스 1950을 1978로 되돌리고 PEcAn이 이미 1978이 있는 것을 감지하면 어떻게 됩니까?).

@mdietze 내 문제는 XML 파일의 자동 구성이 아니라 그 구성이 두 개의 서로 다른 시스템에 분산되어 있다는 것입니다. PEcAn.settings 패키지. 제 생각에는 그리고 전에도 말했듯이 R에서 모든 의미 있는 작업을 수행해야 하고 웹 인터페이스가 R 코드를 호출하는 종이처럼 얇은 래퍼가 되어야 한다고 생각합니다. 이상적인 세상에서는 웹 인터페이스가 완전히 R로 작성되는 것을 보고 싶습니다(Shiny 또는 다른 것을 통해). 또는 웹 인터페이스가 설정하는 많은 기본값은 워크플로 스크립트나 설정 패키지에 의해 설정되어야 한다고 생각합니다. 나에게 그것은 또한 초심자(웹 인터페이스) 사용자에서 중급 사용자로의 전환을 용이하게 할 것입니다.

더 일반적으로, 나는 @serbinsh 의 요점에 100% 동의합니다. 어떤 사용자 구성 옵션이 필요하고 어떤 것이 필요하지 않은지 말하기 어렵습니다. 부분적으로 이것은 문서 문제이지만 최소 필수 사용자 구성을 가능한 한 작게 유지해야 한다고 생각하는 경향이 있습니다.

• 기본 동작이 고급 편집을 수행하거나 xml을 수동으로 구성하는 기능을 무시하는 것을 원하지 않기 때문에 workflow.R 및 PEcAn.settings에 푸시할 수 있는 항목에 제한이 있습니다.
• 나는 웹 GUI를 개념적 으로 윤기나게 마이그레이션하는 것이 좋지만 실제로는 GUI를 다시 작성하는 훨씬 더 시급한 문제가 있습니다.
• 지금은 PHP를 유지하지만 R로 푸시하고 R이 pecan.xml을 작성하게 하는 하이브리드는 PHP가 구성을 R이 읽을 수 있는 다른 파일 형식으로 작성해야 하기 때문에 나에게 약간 어리석은 것처럼 보입니다. 그런 다음 pecan.xml을 작성하십시오. 나에게 이것은 불필요한 추가 단계를 만드는 것처럼 보입니다.
• 예, 문서는 [필수] 항목과 그렇지 않은 항목에 대해 명확해야 합니다. IMHO pecan.xml 문서는 기본 이상을 수행하는 경우 반드시 읽어야 하며 문서를 수정하는 데 있어 매우 높은 우선 순위 를 가져야 합니다. 지금 그 문서는 met.start/end가 필요하다고 표시하지 않지만(변경할 때까지 해야 함) 해당 태그는 첫 번째 '최소' 예제에 포함되어 있습니다.
• 이 특정 문제는 met.start/end가 명시적으로 설정되지 않은 경우에 대해 PEcAn.settings::prepare.settings에 met.start/end = run start/end 가정을 추가함으로써 완화될 수 있다고 생각합니다. 그러면 '필수' 태그 수가 2로 줄어듭니다.

이 문제는 365일 동안 활동이 없었기 때문에 유효하지 않습니다.