text:
Compilation error for python3_script.cc.

Describe the Problem
When compiling on a Mac, I get the following compilation error from python3_script.cc:
python3_script.cc:179:55: error: ordered comparison between pointer and zero ('PyObject *' (aka '_object *') and 'int')
if ( PyRun_String(command, Py_file_input, Dict, Dict) < 0 )  {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
Expected Behavior
I expect the code to compile without error.
Environment
Describe your runtime environment:

Machine: Mac laptop
OS: Catalina (v10.15.3)
MET master_v9.0 development branch.
Compiler version number:
/usr/bin/g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

To Reproduce
Compile MET version 9.0 on a Mac.
Relevant Deadlines
Please include fix in the next met-9.0 bugfix release.
Funding Source
NONE
Define the Metadata
Assignee

[X] Select engineer(s) or no engineer required
[X] Select scientist(s) or no scientist required

Labels

[X] Select component(s)
[X] Select priority
[X] Select requestor(s)

Projects and Milestone

[X] Review projects and select relevant Repository and Organization ones
[X] Select milestone

Committed fixes to the master_v9.0 and develop branches.
No code review necessary for this simple bugfix.

repo: NCAR/MET


text:
review change in results from DILI query

Previously there were more results, but now it is reduced to 2.

cc @karafecho

Old results:
{
  "message": {
    "query_graph": {
      "nodes": {
        "n0": {
          "ids": [
            "NCBIGene:3105",
            "NCBIGene:3106",
            "NCBIGene:64167",
            "NCBIGene:60412",
            "NCBIGene:26191"
          ],
          "categories": [
            "biolink:GeneOrGeneProduct"
          ]
        },
        "n1": {
          "categories": [
            "biolink:GeneOrGeneProduct"
          ]
        }
      },
      "edges": {
        "e0": {
          "predicates": [
            "biolink:affects"
          ],
          "subject": "n0",
          "object": "n1"
        }
      }
    },
    "knowledge_graph": {
      "nodes": {
        "NCBIGene:51752": {
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:Gene",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing"
          ]
        },
        "REACTO:REACTO_R-HSA-983125": {
          "name": "ERAP1/2",
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:ChemicalSubstance",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:Protein"
          ]
        },
        "NCBIGene:51128": {
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:Gene",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing"
          ]
        },
        "REACTO:REACTO_R-HSA-211498": {
          "name": "SAR1B",
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:ChemicalSubstance",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:Protein"
          ]
        },
        "NCBIGene:64167": {
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:Gene",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing"
          ]
        },
        "UniProtKB:Q9NZ08": {
          "name": "ERAP1 Hsap",
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:ChemicalSubstance",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:Protein"
          ]
        },
        "UniProtKB:Q6P179": {
          "name": "ERAP2 Hsap",
          "categories": [
            "biolink:BiologicalEntity",
            "biolink:ChemicalSubstance",
            "biolink:GenomicEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:Protein"
          ]
        },
        "UBERON:0001062": {
          "name": "anatomical entity",
          "categories": [
            "biolink:AnatomicalEntity",
            "biolink:BiologicalEntity",
            "biolink:NamedThing",
            "biolink:OrganismalEntity"
          ]
        }
      },
      "edges": {
        "b59197211574af85b6c125b634d634300e172fa702cf9757fdbed91f2ffb6530": {
          "predicate": "biolink:affects",
          "subject": "REACTO:REACTO_R-HSA-983125",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "6a67d0c10e9ad56cde76a7f3e10d7ba4529365f5f91d275e38a4cad17d9b2f93": {
          "predicate": "biolink:affects",
          "subject": "NCBIGene:64167",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "1c0b2260bc332a1bdc2bdbb9d2047b49f84bd6b1b072f520cabd842a9566bdb0": {
          "predicate": "biolink:affects",
          "subject": "NCBIGene:64167",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "f46dd3973231c0dfd339a9dbe0e2b25219c82ef6c3106f59f91bea8b5c66f86b": {
          "predicate": "biolink:affects",
          "subject": "NCBIGene:51752",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "8f38fb3068f919d094aede988db6e58f5e89c8b70fe06c9c17fed2033beaba1a": {
          "predicate": "biolink:affects",
          "subject": "NCBIGene:51752",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "98c654b1a8f83417dc8439bb993d2c4cce306354c27e4236bb875fed61deed3d": {
          "predicate": "biolink:affects",
          "subject": "UBERON:0001062",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "2fe93c60f5da404012a7a30bc6794670788bb659099a4a75a7f4bb37063ad719": {
          "predicate": "biolink:affects",
          "subject": "REACTO:REACTO_R-HSA-983125",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "8e0f993d9671c79a58c385072763a0333374d601b655284741c5fe9b556c8f4a": {
          "predicate": "biolink:affects",
          "subject": "UniProtKB:Q6P179",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "fb8e844c543714a4d7478f20688d5a0a03ab021c500f3ee21e16bcfcfc3f5745": {
          "predicate": "biolink:affects",
          "subject": "UniProtKB:Q9NZ08",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "db3899cda1193ab64000fe7fe6f5053125dba946e11ce5890c20ee5f51b12482": {
          "predicate": "biolink:affects",
          "subject": "UniProtKB:Q6P179",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "1b30166c4089c1148c289343f14d195709ddc2de71784edac06e5c5eb4e7fc38": {
          "predicate": "biolink:affects",
          "subject": "UniProtKB:Q9NZ08",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "291b328cabb482aec9fd738cb8c047e2680a6d08ae6319dcd59dc94c60d3b5a1": {
          "predicate": "biolink:affects",
          "subject": "UBERON:0001062",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        }
      }
    },
    "results": [
      {
        "node_bindings": {
          "n0": [
            {
              "id": "REACTO:REACTO_R-HSA-983125"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "b59197211574af85b6c125b634d634300e172fa702cf9757fdbed91f2ffb6530"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:51752"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "8f38fb3068f919d094aede988db6e58f5e89c8b70fe06c9c17fed2033beaba1a"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:64167"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "1c0b2260bc332a1bdc2bdbb9d2047b49f84bd6b1b072f520cabd842a9566bdb0"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UniProtKB:Q6P179"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "8e0f993d9671c79a58c385072763a0333374d601b655284741c5fe9b556c8f4a"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UniProtKB:Q9NZ08"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "1b30166c4089c1148c289343f14d195709ddc2de71784edac06e5c5eb4e7fc38"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UBERON:0001062"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "291b328cabb482aec9fd738cb8c047e2680a6d08ae6319dcd59dc94c60d3b5a1"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "REACTO:REACTO_R-HSA-983125"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "2fe93c60f5da404012a7a30bc6794670788bb659099a4a75a7f4bb37063ad719"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:51752"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "f46dd3973231c0dfd339a9dbe0e2b25219c82ef6c3106f59f91bea8b5c66f86b"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:64167"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "6a67d0c10e9ad56cde76a7f3e10d7ba4529365f5f91d275e38a4cad17d9b2f93"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UniProtKB:Q6P179"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "db3899cda1193ab64000fe7fe6f5053125dba946e11ce5890c20ee5f51b12482"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UniProtKB:Q9NZ08"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "fb8e844c543714a4d7478f20688d5a0a03ab021c500f3ee21e16bcfcfc3f5745"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "UBERON:0001062"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "98c654b1a8f83417dc8439bb993d2c4cce306354c27e4236bb875fed61deed3d"
            }
          ]
        }
      }
    ]
  },
  "status": "Success"
}

New results:
{
  "message": {
    "query_graph": {
      "nodes": {
        "n0": {
          "ids": [
            "NCBIGene:3105",
            "NCBIGene:3106",
            "NCBIGene:64167",
            "NCBIGene:60412",
            "NCBIGene:26191"
          ],
          "categories": [
            "biolink:GeneOrGeneProduct"
          ]
        },
        "n1": {
          "categories": [
            "biolink:GeneOrGeneProduct"
          ]
        }
      },
      "edges": {
        "e0": {
          "predicates": [
            "biolink:affects"
          ],
          "subject": "n0",
          "object": "n1"
        }
      }
    },
    "knowledge_graph": {
      "nodes": {
        "NCBIGene:51128": {
          "categories": [
            "biolink:ChemicalEntity",
            "biolink:Gene",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:NucleicAcidEntity"
          ]
        },
        "NCBIGene:64167": {
          "categories": [
            "biolink:ChemicalEntity",
            "biolink:Gene",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:NucleicAcidEntity"
          ]
        },
        "REACTO:REACTO_R-HSA-211498": {
          "name": "SAR1B",
          "categories": [
            "biolink:ChemicalEntity",
            "biolink:MolecularEntity",
            "biolink:NamedThing",
            "biolink:Polypeptide",
            "biolink:Protein"
          ]
        }
      },
      "edges": {
        "9b33b51a0690a5d35ebf243591754675d0d54853ad55f24cfe4889b9ef115ce1": {
          "predicate": "biolink:affects_activity_of",
          "subject": "NCBIGene:64167",
          "object": "REACTO:REACTO_R-HSA-211498",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        },
        "39f762784cf00e5b8c63943200d45bb2cffda2343e11135244c66a8915f3e598": {
          "predicate": "biolink:affects_activity_of",
          "subject": "NCBIGene:64167",
          "object": "NCBIGene:51128",
          "attributes": [
            {
              "attribute_source": "infores:cam_kp",
              "attribute_type_id": "biolink:original_knowledge_source",
              "value": [
                "http://model.geneontology.org/R-HSA-983170"
              ],
              "value_type_id": "biolink:InformationResource",
              "value_url": "http://model.geneontology.org/R-HSA-983125_R-HSA-983158_controller"
            }
          ]
        }
      }
    },
    "results": [
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:64167"
            }
          ],
          "n1": [
            {
              "id": "REACTO:REACTO_R-HSA-211498"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "9b33b51a0690a5d35ebf243591754675d0d54853ad55f24cfe4889b9ef115ce1"
            }
          ]
        }
      },
      {
        "node_bindings": {
          "n0": [
            {
              "id": "NCBIGene:64167"
            }
          ],
          "n1": [
            {
              "id": "NCBIGene:51128"
            }
          ]
        },
        "edge_bindings": {
          "e0": [
            {
              "id": "39f762784cf00e5b8c63943200d45bb2cffda2343e11135244c66a8915f3e598"
            }
          ]
        }
      }
    ]
  },
  "status": "Success"
}

One thing you might want to consider is increasing your input gene list by, for example, including additional HLA genes.

@Shalsh23 : Please be sure to add your query and output to this folder. csv version of output would be very helpful. Thanks!

The following constraint added to the query in some recent commit is responsible for the reduced results of the above query.
https://github.com/NCATS-Tangerine/cam-kp-api/blob/fac70d46eb63e1ca15ebaac24007343b30a2d573/src/main/scala/org/renci/cam/QueryService.scala#L168

That's good to know! Now would be useful to list which types no longer have the right biolink class, just to see if we expect them to.

source: gharchive/issue

authors: Shalsh23 balhoff karafecho

repo: NCATS-Tangerine/cam-kp-api

license: MIT

license_type: permissive

license_source: github-api


text:
NzTree checkedKeys Missing Option

What problem does this feature solve?
For example: When I only checked a subset,Does not contain the indeterminate parent NzTreeNode.
What does the proposed API look like?
Hope to have a contain option

@kainOnly  you can iterate over this node to get all the children, will support flatCheckedKeys (one dimensional array) to get all checked nodes.
demo:
  // get node's children. splitCheckedNodeList = []
  deepCheckNode(node: NzTreeNode): void {
    this.splitCheckedNodeList.push(node);
    if (node.getChildren().length > 0) {
      node.getChildren().filter(cNode => cNode.isAllChecked === true).forEach(cNode => {
        return this.deepCheckNode(cNode);
      });
    }
  }

authors: kainOnly simplejason

repo: NG-ZORRO/ng-zorro-antd


text:
NG-ZORRO v1 升级指南

NG-ZORRO v1 升级指南

本指南适用于当前版本 ng-zorro-antd >= 0.7.x ;
如果在升级过程中遇到问题，欢迎提出。提问前请阅读 如何向开源社区提问题
如果发现本指南存在遗漏/错误，请指出!
或者你遇到了新的问题并解决了，欢迎补充!

开始之前

首先确保你的环境满足以下要求，不确定请直接安装最新 Node.js。

node >= 8.9.0
npm  >= 5.5.1

创建新的分支，或者使用其他方式备份当前项目。
删除项目下 package-lock.json 文件。

升级步骤
第一步 - 升级 Angular CLI
这一步会自动生成最新的配置文件，在项目下执行：
$ npm install -g @angular/cli
$ npm install @angular/cli
$ ng update @angular/cli

第二步 - 升级 Angular 相关依赖
这一步会升级 TypeScript, RxJs 以及 @angular/{packages} 的相关依赖，在项目下执行：
$ ng update @angular/core
$ ng update

第三步 - 升级 NG-ZORRO
在项目下执行：
$ npm install ng-zorro-antd@latest --save

删除 forRoot, 在 app.module.ts 中修改:

@NgModule({
  imports     : [
-    NgZorroAntdModule.forRoot()
+    NgZorroAntdModule
  ]
})

接下来根据以下情况选择修复样式：
情况一 无自定义样式
在项目下的 angular.json 中找到 styles 属性，按以下方式修改：
"styles": [
-  "../node_modules/ng-zorro-antd/src/ng-zorro-antd.less"
+  "node_modules/ng-zorro-antd/src/ng-zorro-antd.min.css"
]

情况二 有自定义样式
执行以下命令，降级 less 到 2.7 版本 为什么？
npm install less@2.7.0 -D
找到引入过 ng-zorro-antd 的样式文件，按照以下方式修改:
- @import "~ng-zorro-antd/**";
+ @import "../node_modules/ng-zorro-antd/**";

第四步 修复 RxJs
安装引入路径修复工具 npm install -g rxjs-tslint
在项目下运行 rxjs-5-to-6-migrate -p src/tsconfig.app.json (rxjs 使用量大的会比较慢)
此时运行 ng serve ，你可能会看见很多 rxjs 的错误信息。接下来将报错的文件按照以下方式修改：

操作符(operators) 统一在 rxjs/operators 中引入。
Observable 创建函数统一在 rxjs 中引入。
操作符(operators) 在 pipe 中使用。
需要重命名的或弃用的到 这里 查看。

例子（之前）
import { Observable } from 'rxjs';

Observable.fromEvent(inputRef, 'input')
.debounceTime(500)
.distinctUntilChanged()
.subscribe(() => { ... })

例子（之后）
import { fromEvent } from 'rxjs';
import { debounceTime, distinctUntilChanged } from 'rxjs/operators';

fromEvent(inputRef, 'input')
.pipe(
  debounceTime(500),
  distinctUntilChanged()
).subscribe(() => { ... })

常见问题
Inline JavaScript is not enabled
ERROR in ./src/app/pages/xxx/index.less
Module build failed:

// https://github.com/ant-design/ant-motion/issues/44
.bezierEasingMixin();
^
Inline JavaScript is not enabled. Is it set in your options?
      in xx/node_modules/ng-zorro-antd/src/style/color/bezierEasing.less (line 110, column 0)
ERROR in ./src/styles.less (./node_modules/raw-loader!./node_modules/postcss-loader/lib??embedded!./node_modules/less-loader/dist/cjs.js??ref--15-3!./src/styles.less)

降级 less 到 2.7，npm install less@2.7.0 -D
less wasn't found
ERROR in ./xxx/index.less
Module build failed:

@import "~ng-zorro-antd/src/style/color/colors.less";
^
'~ng-zorro-antd/src/style/color/colors.less' wasn't found. Tried - xxx/~ng-zorro-antd/src/style/color/colors.less,~ng-zorro-antd/src/style/color/colors.less
      in /Users/hsuanlee/Projects/stream-6.0/src/theme.less (line 1, column 0)
ERROR in ./src/styles.less (./node_modules/raw-loader!./node_modules/postcss-loader/lib??embedded!./node_modules/less-loader/dist/cjs.js??ref--15-3!./src/styles.less)

修改从 node_modules 中引入样式文件中的的路径
- @import "~ng-zorro-antd/**";
+ @import "../node_modules/ng-zorro-antd/**";

Missing locale data for the locale '..'..
请在 main.ts 或 app.module.ts 添加以下代码注册国际化。
import { registerLocaleData } from '@angular/common';
import zh from '@angular/common/locales/zh';

registerLocaleData(zh);

RxJs
查看  官方升级指南

RxJS v5.x to v6 Update Guide
Angular Update Guide
ng-zorro-antd 升级 Angular6 指引 By @cipchk

我從 0.6x 升到 1.x ... styling 完全跑掉欸

@karocksjoelee 0.6 到 0.7 有较大的不兼容升级
样式从emulated 改成到了全局，这样才可以支持自定义主题
两个版本的文档都保留了，可以对照一下

@vthinkxie 原來如此, 好的謝謝

0.6到0.7，然后0.7到1.0.0，用这个不成功

除了降级 less 到 2.7 版本，还需要安装"less-loader": "~4.0.0",

angular-cli@6.1.5 版本已经修复LESS的Inline JavaScript这个问题
pr：https://github.com/angular/angular-cli/pull/11958/commits/f9de24a0aac3e4a427fe025c7b55c6cf1cd43523

from v0.5 to v1.4. I met some Errors. please can u help me. thx!
node_modules/ng-zorro-antd/antd"' has no exported member 'NzModalSubject'.
error TS2339: Property 'open' does not exist on type 'NzModalService'.

ng update/init was remove
https://github.com/angular/angular-cli/issues/4416

我從 0.6x 升到 1.x ... styling 完全跑掉欸

您好，我升级之后 样式也完全跑掉了，请问你是怎么解决的呀

@karocksjoelee， 您好，我升级之后 样式也完全跑掉了，请问你是怎么解决的呀

@karocksjoelee， 您好，我升级之后 样式也完全跑掉了，请问你是怎么解决的呀

因為他是不兼容升級，我那時候是手動改 .. 記得是 service 跟一些 component input 名稱

authors: Flcwl chenby giscafer hsuanxyz huangyuanzhen karocksjoelee liwei511 mingmLiang vthinkxie


text:
Order of DOM nodes in a button is not respected

Reproduction link
https://ng-zorro-antd-start-vjhban.stackblitz.io
Steps to reproduce
Make a component with an input. Use a button with an icon. Use interpolation in the view to display some text before the icon. It does not work.
It works when theres is no binding/interpolation in the HTML
What is expected?
The order of the HTML should be respected
What is actually happening?
The order is not respected. The icon comes before the text
It might because of the  moveIcon method in nz-button-component.ts. I am taking a look

Environment
Info

ng-zorro-antd
7.0.2

Browser
Chrome latest

@chabb Please check out this demo https://ng.ant.design/components/button/en#components-button-demo-size. Button could be placed after text.

authors: chabb wendzhue


text:
二次封装nz-table组件，通过引用不能批量设置属性nzData。

Reproduction link
https://ng-zorro-antd-start-xkvisa.stackblitz.io
Steps to reproduce
见代码链接
What is expected?
能通过引用批量设置nzData属性。
What is actually happening?
暂时不能

Environment
Info

ng-zorro-antd
7.3.3

Browser
google

1.8版本是可以这样使用的，升级到v7版本就不能使用了。希望能兼容。

这样批量设置nzData，在项目中可以封装起来使用，而不是挨个nz-table去写nzData属性。在1.8版本是可以这样设置（代码链接），好奇升级到v7版本就不行了

参考 angular 官网的 OnPush 部分

authors: ANGULAR-X vthinkxie


text:
按tab键切换到select,多次操作按tab键从select失去焦点只会触发1次nzBlur--Press the tab key to switch to select, press the tab key multiple times to lose focus from select and only trigger 1 time nzBlur

Reproduction link
https://stackblitz.com/edit/angular-8lvwrd
Steps to reproduce
鼠标点击username,然后tab切换到select,然后再按一次tab切换到password,循环这个操作,select只会触发一次nzBlur.Mouse click on username, then tab to select, then press tab again to switch to password, loop this operation, select will only trigger nzBlur once.
What is expected?
每次按tab剪从select失去焦点都触发nzBlur.Each time you press tab to remove focus from select, it triggers nzBlur
What is actually happening?
只会触发一次nzBlur.Will only trigger nzBlur once

Environment
Info

ng-zorro-antd
8.0.1

Browser
chrome 74

select是在未展开状态下才会有这个bug.Select is in the unexpanded state will have this bug

https://stackblitz.com/edit/angular-8lvwrd-j5acw4?file=src/app/app.component.ts


text:
refactor(module:qrcode): use the new control flow

PR Checklist
Please check if your PR fulfills the following requirements:

[X] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[X] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?
Qrcode component still use the older control flow
Issue Number: N/A
What is the new behavior?
Qrcode component now use the new control flow
Does this PR introduce a breaking change?
[ ] Yes
[X] No

Other information

LGTM

source: gharchive/pull-request


text:
Document the new model structure

Document the new Data Dictionary in Mauro model structure and how to 'Edit' the content within Mauro.
Definition of Done:

Every Data Dictionary UML stereotype, there is a map to it's destination in Mauro model.
Similarly for Terminologies Data Sets and Code Sets.

Is this required?

Work Instructions and Wiki being created with help from James so issue closed.

authors: AngelaFaulding GSChandel

repo: NHSDigital/DataDictionaryPublication


text:
Add pre-commit hooks

Explore pre-commit githooks

I am a big fan of this idea

authors: fmcclean m-misiura

repo: NICD-UK/project-template


text:
"zones" configuration is case sensitive

If an user configure the zones in WEB-INF/configuration.properties using uppercase (for example, COM instead of com), the web server throws the following exception:
SEVERE [localhost-startStop-1] mx.nic.rdap.sql.model.zoneModel.validateConfiguratedZones Configured zone not found in database: COM
Wouldn't be more user-friendly if this kind of validation were case insensitive? As far as I know, TLD aren't case sensitive, so It could be possible that an user configures his zones according to this rule.

Verified. The zones configuration is changed to lowercase and then validated, so the user can configure using only uppercase.

repo: NICMx/rdap-server

license_source: bigquery


text:
Update template.Rmd

Remove syst.date and some other minor edits

Passing my own PR

repo: NINAnor/ecosystemCondition


text:
Updated readme

Fixes : #1
Did you read the instructions in the README?

Y

Have you read the instructions in CONTRIBUTING?

Y

Have you written this article by yourself? Have you taken inspiration from anywhere and then written it in your words?

Written myself

Written index in the README.MD with each topic title in its respective topic and a direct link to the article.

@samagragupta I have requested some changes. Do them and we are good to merge.

@the-ethan-hunt Done the changes

Merging it

authors: samagragupta the-ethan-hunt

repo: NJACKWinterOfCode/first-timers-guide


text:
掩码处理

作者您好，请问您对掩码的具体处理是怎样的哪？

四种病变的标签是放在同一个mask中，跟普通语义分割一样，四种病变用1,2,3,4代表就行，背景用0代表就可以。

感谢作者回复，我已成功处理标签并复现。

authors: NKUhealong WHLWJL

repo: NKUhealong/PMCNet


text:
The refresh flag is not working for large values

We were trying to increase the interval between consecutive refreshes (--refresh) to a large value for testing purposes. It seems there is an upper bound to the length of intervals: the interval will always be around 1.5 hours even if the value of the flag is way larger than 1.5 hours (we used 86400 seconds in our experiments). I monitored the interval length by checking the timestamps in /status.

The refresh value is only the upper bound of the refresh time. If objects in the repository expire before that time, a new validation run will start earlier.

Thanks for replying! So there's no way to prevent a validation from happening? We are exploring options of holding the next validation until a certain amount of time. I guess "--expire" will not do the work as well as I tried large values (172800) and it doesn't make any difference.

So there's no way to prevent a validation from happening?

Not currently, I am afraid. The intention here was to not serve expired objects.
May I ask what your reason for wanting to delay validation runs is?

I guess "--expire" will not do the work as well [...]

No, this is currently only used in the timer values sent to RTR clients.

We have some pipelines to download VRPs periodically through Routinator, and we want to build a routine test to make sure our origin validator works the same as the Routinator given the same set of VRPs. Therefore, we do not really want the Routinator to refresh -- otherwise the validation outputs may be slightly different as Routinator can have a newer set of VRPs. We want to increase the interval between refreshes so that we can decrease the chance of hitting validations.
Just in case you are curious - theoretically we will experience content changes as long as the interval is not infinity, but if the interval is large enough and we time it well it should be rare to see diffs in outputs.

If you are okay with using Routinator from the command line instead of the HTTP service, you could use a combination of the update command together with vrps or validate using the --noupdate option. This way, you could run update periodically to update the cache and then stick to that cache via --noupdate. However, make sure that update doesn’t overlap with other runs as the cache may be inconsistent during an update run.

Got it, thanks for the idea! However, we may expect to validate a lot of prefixes (> 1 million) in a test, and running commands is just a bit to slow for us...
I am also wondering if it's possible to add a --noupdate flag to the HTTP server. Is it very difficult to do something like this?

It would certainly be doable but I am a bit hesitant to have a server that doesn’t update.
How about adding an option to the validate command to read the input from a file and produce a file? Would that help you?

Yes, validation through a file will definitely help! Do you want me to submit another feature request or we can just stick with this issue?

Keeping this one is fine. I’ll just rename it.

authors: barryhe partim

repo: NLnetLabs/routinator


text:
Rewrite Asserts for concurrenttest for better diag

for https://github.com/NLog/NLog/issues/2329

at least back to 19 min

repo: NLog/NLog


text:
Provide mapping best practices for aircraft evaluation

Need to think about how we can convey how to do the mapping (model to observations) especially for various VOCs for the aircraft evaluation. This will be campaign and model/mechanism specific, so potentially some example mapping in excel for mechanisms and campaigns we typically use at NOAA and NCAR to get people started in the examples folder and explained in the ReadTheDocs? Let's think about how to convey this best practice information as we develop the aircraft analysis scripts.

An example of something I started for FIREX DC8 data and MOZART chemistry:
https://docs.google.com/spreadsheets/d/1s5Dqs7iHJLV1slSLYS2xfxOH7rFW5mBh/edit?usp=sharing&ouid=105024720870979784865&rtpof=true&sd=true

authors: lkemmons rschwant

repo: NOAA-CSL/MELODIES-MONET


text:
Update reading in paired data for satellite evaluation

Satellite group mentioned that your method of reading in the paired data does not perfectly work for their needs (https://melodies-monet.readthedocs.io/en/latest/examples/read_paired_data.html) since you have to read in the yaml file, read in the obs, and model output and effectively you just skip the pairing step.
They want to be able to use the paired data for analysis and plotting without having to re-read in the model and observation data. Options to do this:
Store the meta data in the analysis class?
Or have an option to read in the observations and model output, but just to grab the meta data and not save the full output?
Or others?
Maggie (@mebruckner ) said she wrote in a way to bypass the reading in the observational data for now. Need to identify best way to update this for the future.
We would need to keep both options though. Because for contour overlay plots you would still need to read in the model output again fully and the paired output to make this plot.

To re-load the attributes for the model and observation classes I added the following to the read_analysis method:
https://github.com/mebruckner/MELODIES-MONET-1/blob/61d0ee616b8c2d3d59e916c43daa09f30f4a3f2d/melodies_monet/driver.py#L643-L646
load_files is an optional argument I added to open_models and open_obs that defaults to True. Within the methods, I then added an if load_files statement around open_model_files and open_obs

authors: mebruckner rschwant


text:
Update package script fails if wheel package not installed

Installing packages using scripts/update_package.sh fails if wheel package is not installed in environment.
Current behavior

clone repo

create virtual environment and update pip
python -m venv venv
source ./venv/bin/activate
python -m pip install -U pip

run scripts/update_package.sh

fails because wheel not installed

Expected behavior

wheel is installed, if required and scripts/update_package.sh does not fail

Proposed solution
In short, add pyproject.toml configuration file to all subpackages and specify wheel as a build time dependency.
PEP 518 -- "Specifying Minimum Build System Requirements for Python Projects", introduced the ability to specify build requirements in a new pyproject.toml configuration file. This file is respected and used by package installers (i.e. pip) to verify that build time dependencies are satisfied and installed if required.
Assuming this solution is accepted, before introducing pyproject.tomls, it is prerequisite that we determine the minimum required wheel and setuptools versions.

I don't see this as a bug, per se.  The issue is that step 2 doesn't include the command to install things from requirements.txt.  Those project development dependencies are documented in doc/DEPENDENCIES.md, and those details are referenced and linked within the main README.md.  There are also helper options for that in scripts/update_package.sh.
All that said, this certainly demonstrates that things aren't already handled perfectly and that we should look at improvements.

In short, add pyproject.toml configuration file to all subpackages and specify wheel as a build time dependency.

I am fine with going this direction, but if this isn't a bug or otherwise essential, we will need to prioritize it lower.

I don't see this as a bug, per se. The issue is that step 2 doesn't include the command to install things from requirements.txt. Those project development dependencies are documented in doc/DEPENDENCIES.md, and those details are referenced and linked within the main README.md. There are also helper options for that in scripts/update_package.sh.

Austin, just read the manual... haha. That's fair. My only rebuttal, if you would even call it that :), is that I think you should be able to install a package's dependencies through setup.py or an equivalent package metadata file. That implies that for any package, all required dependencies for that package are all listed in its setup.py. This is not the case at the moment.

I'm bumping the project priority of this to High, and will move into Accepted.  Given our hopes for accelerated involvement of others in the community in the near term, we want to get rid of roadblocks like this.

authors: aaraney robertbartel

repo: NOAA-OWP/DMOD


text:
Missing Environment Variables or libraries are not reported by unit tests

If you run unit tests on fresh environments without required environment variables set or libraries installed, you may see:
$ ./scripts/run_tests.sh
Executing unit tests on supported packages ...

python/lib/access:  ()
python/lib/client:  ()
python/lib/communication:  ()
python/lib/core:  ()
python/lib/evaluations:  ()
python/lib/externalrequests:  ()
python/lib/hydrofabric:  ()
python/lib/metrics:  ()
python/lib/modeldata:  ()
python/lib/monitor:  ()
python/lib/redis:  ()
python/lib/scheduler:  ()

where you should see:
$ ./scripts/run_tests.sh
Executing unit tests on supported packages ...

python/lib/access: OK (Ran 0 tests in 0.000s)
python/lib/client: OK (Ran 4 tests in 0.000s)
python/lib/communication: OK (skipped=20) (Ran 272 tests in 0.148s)
python/lib/core: FAILED (failures=1) (Ran 57 tests in 0.009s)
python/lib/evaluations: FAILED (errors=11) (Ran 372 tests in 5.913s)
python/lib/externalrequests: OK (Ran 25 tests in 0.009s)
python/lib/hydrofabric: OK (Ran 5 tests in 0.003s)
python/lib/metrics: OK (Ran 29 tests in 0.357s)
python/lib/modeldata: OK (Ran 54 tests in 3.577s)
python/lib/monitor: OK (Ran 0 tests in 0.000s)
python/lib/redis: OK (Ran 8 tests in 0.000s)
python/lib/scheduler: FAILED (errors=8, skipped=10) (Ran 119 tests in 26.200s)

There is no output stating that libraries or environment variables may be missing. As a result, unit testing
becomes pointless.
Ideally, this should print errors that may have prevented data from being generated (such as printing stderr if the exit code was not 0) and exiting with a non-zero return code if unable to successfully run tests.

In this case my fresh environment didn't have the virtual environment set up. The test was able to run even though it a) didn't have a virtual environment and b) wasn't activated. This probably should have checked if the environment existed prior to running the tests.


text:
Codes to generate GIUH, extract NWM 2.1 params from hydrofabrics and create config file for CFE.

Adding codes.
Additions

Removals

Changes

Testing

Screenshots
Notes

Todos

Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows project standards (link if applicable)
[ ] Passes all existing automated tests
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged / future todos are captured in comments
[ ] Visually tested in supported browsers and devices (see checklist below :point_down:)
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
[ ] Reviewers requested with the Reviewers tool :arrow_right:

Testing checklist
Target Environment support

[ ] Windows
[ ] Linux
[ ] Browser

Accessibility

[ ] Keyboard friendly
[ ] Screen reader friendly

Other

[ ] Is useable without CSS
[ ] Is useable without JS
[ ] Flexible from small to large screens
[ ] No linting errors or warnings
[ ] JavaScript tests are passing

@lcunha0118, please remove all output files and add their pattern to a .gitignore as @madMatchstick recommended for TOPMODEL

repo: NOAA-OWP/cfe


text:
Provide an example realization file which uses a python model

As we have refactored the examples under data, we may have lost an example of a python bmi realization definition (I was pretty sure there was one at some point, but there isn't now that I can see...)
Current behavior
There are no example realizations of a stand alone or multi bmi model that uses a python model.
Expected behavior
Provide sample realization and multi realization that shows the python module integration.

I am actually not sure there was one, but it's possible there was and it's been lost. None of the current "bundled" models are Python except test_bmi_python, should we use that one?

repo: NOAA-OWP/ngen


text:
K8s dev

This pull request adds a Dockerfile as well as instructions for building the Dockerfile and running the scripts images_to_samples.py, train_segmentation.py, and inference.py in the docker image. I've also added instructions for building and running the image on remote computers.

Do you mind bringing your PR up to date as I would like to merge the latest updates from 'develop' into 'K8s' branch I don't think there would be a lot of conflicts with your PR after the update. Based on this I think travis-CI test would pass effortlessly.

Looking at your Dockerfile, I pulled the image you reference on my machine.  It takes up 12 GB of space even though it's advertised at 4.5GB on the nvidia site.  I'm worried about the time spinning such big containers for a real online inference service.
The way we run GDL on our workstations and HPC is we set up cuDNN on the servers themselves, that is system wide.  I understand talking with @victorlazio109 that it may be tricky to get the right version of cuDNN depending on the version of CUDA used by a specific version of PyTorch (am I right @victorlazio109 ?).
I think we should strive to get a lean Dockerfile for GDL (that is, basically wrap our current conda environment in a container) and take for granted our GPU servers are properly set to run the version of PyTorch we want to use in GDL.  Since we will be using a container orchestrator (K8S via Rancher) to run our inference workloads, I think the responsibility of finding the right GPU node should reside in Rancher.  I'm not sure how we can add the right metadata to our K8S cluster nodes so that Rancher knows a node has the right version of cuDNN for the container it is asked to deploy, but I think we should look in that direction.  Even though it may be quicker than I think to launch 12 GB containers, it does not make sense to me to rebuild a GPU runtime that's already on a server.
To that effect, we will be investigating the use of Kubeflow through Rancher soon.  I'll keep you informed when we have something working.  In the meantime, if you could investigate more "efficient" ways to put together a Docker image, that would be great.

authors: krishanr victorlazio109 ymoisan

repo: NRCan/geo-deep-learning


text:
Update ITC and incentives interactions

Based on this article from SETO: https://www.energy.gov/eere/solar/homeowners-guide-federal-tax-credit-solar-photovoltaics, SAM's calculate ITC percentage inputs reduces the ITC basis by too much for a taxable incentive. Update the effects of "taxable" and "reduces basis" checkboxes to align with the guidance in the above article.

SETO article for residential and there is not basis reduction for ITC

Is there a specific SAM case/project file that shows what "effects" of the ITC percentage calculation is incorrect and for what markets?

Whoops. This is the correct article: https://www.energy.gov/eere/solar/federal-solar-tax-credits-businesses
This SAM file shows a case where the ITC basis is reduced by a taxable investment based incentive:
ITC_basis_reduction.zip The ITC credit should remain at $284,459 in this case (same as IBI)
This would also apply to CBI and PBI as well, assuming the taxable box is checked and the reduces bases box is unchecked.

Whoops. This is the correct article: https://www.energy.gov/eere/solar/federal-solar-tax-credits-businesses
This SAM file shows a case where the ITC basis is reduced by a taxable investment based incentive: ITC_basis_reduction.zip The ITC credit should remain at $284,459 in this case (same as IBI)
This would also apply to CBI and PBI as well, assuming the taxable box is checked and the reduces bases box is unchecked.
I agree we should be consulting the rules for residences for the residential case. I believe the rules for businesses above apply to every other case.

In digging through the code, I think the disconnect is the updated installed cost based on any IBI or CBI applied as:

This value affects the ITC percentage as it is based on the installed cost and the Investments and Capacity based incentives act to reduce the installed cost BEFORE the ITC is applied.
So, do we want to rework that equation so that the ITC is always based on the installed cost before IBI and CBI are applied?
The proforma was constructed so that IBI and CBI are applied in year 0 and the ITC was applied in year 1

I am not sure how to proceed here...

Are you saying that the cost_installed in the code above should only be reduced if the IBI and CBI are not taxable?

Yes. Given the checkboxes in the UI, the default of "taxable" and "does not reduce basis" should not run this code. If taxable is not checked, or if reduces basis is checked, then this code should run. Alternatively, we could simplify the code to only run if "reduces basis" is checked, and solve the inter-dependency between the two checkboxes in the GUI/help.

Breaking this into separate issues for each financial market with this issue specific to hots developer and others will be updated accordingly.

I'm not sure exactly what the issue is here:

Is the goal for a IBI and ITC incentive to be the same, i.e., a 30% ITC for a commercial business and 30% direct pay incentive (IBI) for a tax-exempt entity should a) be the same dollar amount, and/or b) have the same effect on the cash flow? If this is true, then I think our test file should compare two cases, one with a 30% ITC and one with a 30% IBI, not a single case with both.

Under what conditions would you have both a 30% IBI and a 30% ITC?

Where in the SETO article does it explain the effect of an IBI or other cash incentive on the ITC basis?

The goal of the test file is to show that the IBI and ITC should be the same in this case.
We encountered this case on PR-ERF, depending on how the incentive is structured.
See this discussion on tax basis, which indicated an error in the current behavior (reducing the ITC for taxable incentives):

@brtietz Thanks for the clarification.
Note the comment about the exception for PV at a residence: SAM's Host / Developer model may be used for a sytem installed on either a residential or commercial property, so we'll need to consider how to handle that correctly.

Thanks. I think in that case the user could check the "reduces basis" box under my "alternatively" scenario above.

I mocked up the first example (taxable with no basis reduction) below:
SAM Financials.zip
The key distinction seems to be whether the incentive is taxable income (the case developed here) or a rebate considered reduction in sale price, which would result in a reduction in basis (see "decreases to basis" on https://www.irs.gov/publications/p551).
I think this requires a new variable. Net capital cost needs to remain as is for other cash flow calculations.
@sjanzou and @cpaulgilman Does this approach make sense to you? If so I'll outline the next batch of cases (basis reduction, credit+ITC more than cost) and look for some reviewers within NREL.

I mocked up the first example (taxable with no basis reduction) below:
SAM Financials.zip
The key distinction seems to be whether the incentive is taxable income (the case developed here) or a rebate considered reduction in sale price, which would result in a reduction in basis (see "decreases to basis" on https://www.irs.gov/publications/p551).
I think this requires a new variable. Net capital cost needs to remain as is for other cash flow calculations.
@sjanzou and @cpaulgilman Does this approach make sense to you? If so I'll outline the next batch of cases (basis reduction, credit+ITC more than cost) and look for some reviewers within NREL.

@brtietz , what is the new variable and how does it affect the depreciation and ITC basis table:

One of the key changes that has switched back and forth is the "issuance_of_equity" and the "purchase_of_property" and the "cost_installed" that have changed, e.g. host developer:

My suggestion would to be to come up with more current terms and be consistent through all the financial models and to use as many IRS publications (or other citable publications) as reference going forward.
Maybe we should add another output table to breakdown the cost_installed and issuance_of_equity and purchase_of_property values use throughout the pro-forma for clarity?

Apologies for not writing that up in more detail. The new variable is the sum of the negative cash flows from investing activities (i.e. without CBI or IBI):

issuance_of_equity, purchase_of_property, and cost_installed should not change relative to patch, but the depreciation allocations and ITC basis should refer to this new variable (as I've set up in Excel in your screenshot).
Thoughts on naming the new variable? "gross_tax_basis"?
I'm a fan of "trace precedents" and "trace dependents" for creating that breakdown, but happy to create a short form.

I think the only existing use of cost_installed that needs to change is: https://github.com/NREL/ssc/blob/6825d95b3263d0f1f3aa23a9661f646cd874ac0d/ssc/cmod_host_developer.cpp#L2285
where it should change to cost_prefinancing + cost_financing. I'd favor reporting that variable out in the cash flow, so it's more than a one line change.

authors: brtietz cpaulgilman sjanzou

repo: NREL/SAM


text:
Look into adding ruff

We currently format the code with black but do not enforce any linting. We could consider using ruff for both formatting and linting, adding it as a dev dependency and then enforcing it's checks and formatting with their github action.

I can take a look at this!

authors: BradonZhang nreinicke

repo: NREL/routee-compass


text:
Update mhk equations for PySAM integration

Describe the bug
-Update cmod linkage for mhk ssc equations in ssc_equations.h for integration in next major release of PySAM.

Closing this for now as a wishlist item.

repo: NREL/ssc


text:
Discounted Payback change discount to year zero instead of year one.

cmod_cashloan - update discounted payback to discount to year zero instead of year 1.  Year 1 discount was made based on the assumption that the user had project up and running in year 1. Discounting to year zero provides consistency with all NPV values and per example provided.

cmod_cashload and the Excel with equations Residential and Commercial workbooks will be updated.


text:
one cause of frozen scans - using ct_dark_all() plan with fast acquition times - intermittent issue

Versions of DAMA software:
- Bluesky    : v1.6.3
- Ophyd      : v1.5.1
- Databroker : v1.0.6
This problem is old and not consistently occurring.  removed all .value in January and that did not help.  seems to happen when exposure time is short and "network" robustness.
successful run has the setpoint never change (camonitor) but the readback value does change
[xf23id1@xf23id-ws3 ~/Beamline/Commissioning/2020_07]$ camonitor XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd_RBV
XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd_RBV 2020-07-31 18:41:04.261963 Off  ### was the immedate after Enter
XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd_RBV 2020-07-31 19:06:06.197300 On  ### happened with plan start
XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd_RBV 2020-07-31 19:06:06.272830 Off

waiting for it to fail again to capture camonitor

In [301]: RE(mv(fccd.exposure, (0.02, .1, 20)))
Out[301]: ()

In [302]: RE(bpp.pchain(ct_dark_all(20),rel_scan([fccd],nanop.by,-.1,0.1,201, md={'purpose':'ZP zoom 1/8 cut'})))

Starting procedure to acquire darks 36.4Hz or 0.028s.

	Current number of images = 20.

	Setting to 20 images.

  A 'deferred pause' has been requested. The RunEngine will pause at the next checkpoint. To pause immediately, hit Ctrl+C again in the next 10 seconds.
Deferred pause acknowledged. Continuing to checkpoint.
^Ctrying a second time
Pausing...
---------------------------------------------------------------------------
RunEngineInterrupted                      Traceback (most recent call last)
~/Beamline/Commissioning/2020_07/MonoStab.py in <module>
----> 1 RE(bpp.pchain(ct_dark_all(20),rel_scan([fccd],nanop.by,-.1,0.1,201, md={'purpose':'ZP zoom 1/8 cut'})))

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in __call__(self, *args, **metadata_kw)
    796
    797         if self._interrupted:
--> 798             raise RunEngineInterrupted(self.pause_msg) from None
    799
    800         return tuple(self._run_start_uids)

RunEngineInterrupted:
Your RunEngine is entering a paused state. These are your options for changing
the state of the RunEngine:

RE.resume()    Resume the plan.
RE.abort()     Perform cleanup, then kill plan. Mark exit_stats='aborted'.
RE.stop()      Perform cleanup, then kill plan. Mark exit_status='success'.
RE.halt()      Emergency Stop: Do not perform cleanup --- just stop.

In [303]: RE.abort()
Aborting: running cleanup and marking exit_status as 'abort'...

Returning to intial conditions (pre-count).
        Total images per trigger are NOW:        20
	FCCD FCRIC gain value is NOW:		 auto

Run aborted
Traceback (most recent call last):
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py", line 1353, in _run
    msg = self._plan_stack[-1].send(resp)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 1307, in __call__
    return (yield from plan)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 1162, in baseline_wrapper
    return (yield from plan_mutator(plan, insert_baseline))
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 803, in monitor_during_wrapper
    return (yield from plan2)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 861, in fly_during_wrapper
    return (yield from plan2)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 268, in pchain
    rets.append((yield from p))
  File "/epics/xf/23id/ipython/profile_collection/startup/csx1/plans/dark_ff.py", line 190, in ct_dark_all
    yield from bps.mv(fccd.fccd1.capture_bgnd, 1)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/plan_stubs.py", line 258, in mv
    yield Msg('wait', None, group=group)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  [Previous line repeated 2 more times]
bluesky.utils.RequestAbort
Out[303]: ()

In [304]: RE(bpp.pchain(ct_dark_all(20),rel_scan([fccd],nanop.by,-.1,0.1,201, md={'purpose':'ZP zoom 1/8 cut'})))

Starting procedure to acquire darks 36.4Hz or 0.028s.

	Current number of images = 20.

	Setting to 20 images.

Returning to intial conditions (pre-count).
        Total images per trigger are NOW:        20
	FCCD FCRIC gain value is NOW:		 auto

Run aborted
Traceback (most recent call last):
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py", line 1353, in _run
    msg = self._plan_stack[-1].send(resp)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 1307, in __call__
    return (yield from plan)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 1162, in baseline_wrapper
    return (yield from plan_mutator(plan, insert_baseline))
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 803, in monitor_during_wrapper
    return (yield from plan2)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 861, in fly_during_wrapper
    return (yield from plan2)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 170, in plan_mutator
    raise ex
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 123, in plan_mutator
    msg = plan_stack[-1].send(ret)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 268, in pchain
    rets.append((yield from p))
  File "/epics/xf/23id/ipython/profile_collection/startup/csx1/plans/dark_ff.py", line 190, in ct_dark_all
    yield from bps.mv(fccd.fccd1.capture_bgnd, 1)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/plan_stubs.py", line 256, in mv
    ret = yield Msg('set', obj, val, group=group, **kwargs)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py", line 195, in plan_mutator
    inner_ret = yield msg
  [Previous line repeated 2 more times]
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py", line 1413, in _run
    new_response = await coro(msg)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py", line 1909, in _set
    ret = msg.obj.set(*msg.args, **kwargs)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/ophyd/signal.py", line 1670, in set
    return super().set(value, timeout=timeout, settle_time=settle_time)
  File "/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/ophyd/signal.py", line 301, in set
    raise RuntimeError('Another set() call is still in progress '
RuntimeError: Another set() call is still in progress for fccd_fccd1_capture_bgnd
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/Beamline/Commissioning/2020_07/MonoStab.py in <module>
----> 1 RE(bpp.pchain(ct_dark_all(20),rel_scan([fccd],nanop.by,-.1,0.1,201, md={'purpose':'ZP zoom 1/8 cut'})))

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in __call__(self, *args, **metadata_kw)
    793             self._task_fut.add_done_callback(set_blocking_event)
    794
--> 795         self._resume_task(init_func=_build_task)
    796
    797         if self._interrupted:

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in _resume_task(self, init_func)
    917                     if (exc is not None
    918                             and not isinstance(exc, _RunEnginePanic)):
--> 919                         raise exc
    920
    921     def install_suspender(self, suspender):

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in _run(self)
   1486             exit_reason = str(err)
   1487             self.log.exception("Run aborted")
-> 1488             raise err
   1489         finally:
   1490             if not exit_reason:

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in _run(self)
   1351                     else:
   1352                         try:
-> 1353                             msg = self._plan_stack[-1].send(resp)
   1354                         # We have exhausted the top generator
   1355                         except StopIteration:

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in __call__(self, plan)
   1305         plan = monitor_during_wrapper(plan, self.monitors)
   1306         plan = baseline_wrapper(plan, self.baseline)
-> 1307         return (yield from plan)
   1308
   1309

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in baseline_wrapper(plan, devices, name)
   1160         return (yield from plan)
   1161     else:
-> 1162         return (yield from plan_mutator(plan, insert_baseline))
   1163
   1164

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    168                     continue
    169                 else:
--> 170                     raise ex
    171         # if inserting / mutating, put new generator on the stack
    172         # and replace the current msg with the first element from the

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    121             ret = result_stack.pop()
    122             try:
--> 123                 msg = plan_stack[-1].send(ret)
    124             except StopIteration as e:
    125                 # discard the exhausted generator

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in monitor_during_wrapper(plan, signals)
    801     plan1 = plan_mutator(plan, insert_after_open)
    802     plan2 = plan_mutator(plan1, insert_before_close)
--> 803     return (yield from plan2)
    804
    805

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    168                     continue
    169                 else:
--> 170                     raise ex
    171         # if inserting / mutating, put new generator on the stack
    172         # and replace the current msg with the first element from the

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    121             ret = result_stack.pop()
    122             try:
--> 123                 msg = plan_stack[-1].send(ret)
    124             except StopIteration as e:
    125                 # discard the exhausted generator

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    168                     continue
    169                 else:
--> 170                     raise ex
    171         # if inserting / mutating, put new generator on the stack
    172         # and replace the current msg with the first element from the

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    121             ret = result_stack.pop()
    122             try:
--> 123                 msg = plan_stack[-1].send(ret)
    124             except StopIteration as e:
    125                 # discard the exhausted generator

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in fly_during_wrapper(plan, flyers)
    859     plan1 = plan_mutator(plan, insert_after_open)
    860     plan2 = plan_mutator(plan1, insert_before_close)
--> 861     return (yield from plan2)
    862
    863

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    168                     continue
    169                 else:
--> 170                     raise ex
    171         # if inserting / mutating, put new generator on the stack
    172         # and replace the current msg with the first element from the

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    121             ret = result_stack.pop()
    122             try:
--> 123                 msg = plan_stack[-1].send(ret)
    124             except StopIteration as e:
    125                 # discard the exhausted generator

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    168                     continue
    169                 else:
--> 170                     raise ex
    171         # if inserting / mutating, put new generator on the stack
    172         # and replace the current msg with the first element from the

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    121             ret = result_stack.pop()
    122             try:
--> 123                 msg = plan_stack[-1].send(ret)
    124             except StopIteration as e:
    125                 # discard the exhausted generator

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in pchain(*args)
    266     rets = deque()
    267     for p in args:
--> 268         rets.append((yield from p))
    269     return tuple(rets)
    270

/epics/xf/23id/ipython/profile_collection/startup/csx1/plans/dark_ff.py in ct_dark_all(numim, detectors)
    188         # SET TO 1 TO ARM FOR NEXT EVENT so that the FastCCD1 is
    189         # already bkg subt
--> 190         yield from bps.mv(fccd.fccd1.capture_bgnd, 1)
    191
    192         # take darks

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/plan_stubs.py in mv(group, *args, **kwargs)
    254     (step,) = utils.merge_cycler(cyl)
    255     for obj, val in step.items():
--> 256         ret = yield Msg('set', obj, val, group=group, **kwargs)
    257         status_objects.append(ret)
    258     yield Msg('wait', None, group=group)

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    193         try:
    194             # yield out the 'current message' and collect the return
--> 195             inner_ret = yield msg
    196         except GeneratorExit:
    197             # special case GeneratorExit.  We must clean up all of our plans

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    193         try:
    194             # yield out the 'current message' and collect the return
--> 195             inner_ret = yield msg
    196         except GeneratorExit:
    197             # special case GeneratorExit.  We must clean up all of our plans

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    193         try:
    194             # yield out the 'current message' and collect the return
--> 195             inner_ret = yield msg
    196         except GeneratorExit:
    197             # special case GeneratorExit.  We must clean up all of our plans

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    193         try:
    194             # yield out the 'current message' and collect the return
--> 195             inner_ret = yield msg
    196         except GeneratorExit:
    197             # special case GeneratorExit.  We must clean up all of our plans

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/preprocessors.py in plan_mutator(plan, msg_proc)
    193         try:
    194             # yield out the 'current message' and collect the return
--> 195             inner_ret = yield msg
    196         except GeneratorExit:
    197             # special case GeneratorExit.  We must clean up all of our plans

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in _run(self)
   1411                         # exceptions (coming in via throw) can be
   1412                         # raised
-> 1413                         new_response = await coro(msg)
   1414
   1415                     # special case `CancelledError` and let the outer

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/bluesky/run_engine.py in _set(self, msg)
   1907         group = kwargs.pop('group', None)
   1908         self._movable_objs_touched.add(msg.obj)
-> 1909         ret = msg.obj.set(*msg.args, **kwargs)
   1910         p_event = asyncio.Event(loop=self.loop)
   1911         pardon_failures = self._pardon_failures

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/ophyd/signal.py in set(self, value, timeout, settle_time)
   1668         '''
   1669         if not self._put_complete:
-> 1670             return super().set(value, timeout=timeout, settle_time=settle_time)
   1671
   1672         # using put completion:

/opt/conda_envs/collection-2020-2.0rc4/lib/python3.7/site-packages/ophyd/signal.py in set(self, value, timeout, settle_time)
    299
    300         if self._set_thread is not None:
--> 301             raise RuntimeError('Another set() call is still in progress '
    302                                f'for {self.name}')
    303

RuntimeError: Another set() call is still in progress for fccd_fccd1_capture_bgnd
n [305]:

In [305]: fccd.fccd1.capture_bgnd

Out[305]: EpicsSignalWithRBV(read_pv='XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd_RBV', name='fccd_fccd1_capture_bgnd', parent='fccd_fccd1', value=0, timestamp=1596235264.261963, auto_monitor=False, string=False, write_pv='XF:23ID1-ES{FCCD}FastCCD1:CaptureBgnd', limits=False, put_complete=False)

related to https://github.com/NSLS-II-CSX/xf23id1_profiles/issues/25

https://github.com/bluesky/bluesky/issues/1159 other useful discussion.

It's a bit hard to fully understand the issue without the source code from ~/Beamline/Commissioning/2020_07/MonoStab.py. I think we should develop an approach to keep these files in an accessible place. If there is some private information, there can be a private GitHub repo for these things. Here is a similar repo for the SIX beamline, which make it more convenient to provide support: https://github.com/NSLS-II-SIX/science_commissioning.

@mrakitin I don't understand.  then issue I report is using bpp.pchain.  It doesn't come from a script or ,py file
but you are correct in that this GitHub goodness is missing form commissioning plans.  I've allocated a path on the main workstation but haven't had time to creat the repo.  Are there any guidelines form DSSI?
We want the repo to be independent from the profile

@mrakitin I don't understand. the issue I report is using bpp.pchain. It doesn't come from a script or ,py file

Got it. I was confused by the following lines after a quick look at the error:
RunEngineInterrupted                      Traceback (most recent call last)
~/Beamline/Commissioning/2020_07/MonoStab.py in <module>

but you are correct in that this GitHub goodness is missing form commissioning plans. I've allocated a path on the main workstation but haven't had time to creat the repo. Are there any guidelines form DSSI?
We want the repo to be independent from the profile

I think that can be a repo with the name of your preference. The current Commissioning directory can easily be made a repo with just git init and git add <...> commands. I can assist with that.

Following up.  We discussed at the beamline and @mrakitin suggested we use the facility two-button shutter ophyd device because it is heavily tested and more robust.
our two-button shutter is based off of the same ioc, but the strings associated with the state are "In" and "Out" and "Inserted" and "Not Inserted".   @mrakitin liked other aspects of the ophyd device too but he was not sure that we should try to "fix" the facility two-button shutter since it could potentially break a lot for a lot of people.
The inout device is used to block the beam for dark image collection.  ct_darks_all()
Three options:

integrated facility two-button shutter key points into our two-button shutter
change atleast 4 on CSX from "IN" / "OUT" two-button shutter ioc / eps (CSX has two chassis for itself, so this is why EPS) to match standard facility EPS 2-button shutter
make a new version of a "better" two-button shutter (more generalized) and roll it out with V1 still available.

@ambarb, thanks for documenting more details about the issue!

will update with a scan number and the full traceback as there is more information now.

looks like we should check also exception handling when inout fails.  To be clear, inout is not failing; what happens is bluesky thinks it failed.
generator count_flatfield ['0bb2fe57'] (scan num: 156290)
	Setting to 200 images.

** (2022-07-03 16:13:40) Had to reactuate shutter while Ining
** (2022-07-03 16:13:40) Had to reactuate shutter while Ining

Returning to intial conditions (pre-count).
An exception has occurred, use '%tb verbose' to see the full traceback.
FailedStatus: DeviceStatus(device=inout, done=True, success=False)

During handling of the above exception, another exception occurred:
RuntimeError: trying to set while a set is in progress

See /var/log/bluesky/bluesky.log for the full traceback.

@johnsinsheimer I think this is pretty in control, right?  We can test more by letting making the acquire period as small as possible when running the camera at 0.2s or faster.

authors: ambarb mrakitin


text:
Fix unit multi stage deploy inference serving

Newer versions of triton do not allow startup from within the context of a notebook, that is within the context of testbooks. This fix is to remedy those issues.

rerun tests

repo: NVIDIA-Merlin/Merlin


text:
Metrics around capturing gpu FLOPS

The metric "DCGM_FI_PROF_PIPE_FP64_ACTIVE" is defined as the "Ratio of cycles the fp32 pipe is active". I suppose the units is time here. How do we equate this to FLOPS count. For example in A100 as per the article seems to have max of 19.5TFLOPS (count).
Is it reasonably correct to convert the "DCGM_FI_PROF_PIPE_FP64_ACTIVE" % in absolute FLOP count? i.e 50% value of
DCGM_FI_PROF_PIPE_FP64_ACTIVE == 0.5 * 19.5 = 9.75 TFLOPS?
There also seems to be different pipes for 16/32 bit operations(DCGM_FI_PROF_PIPE_FP16_ACTIVE/DCGM_FI_PROF_PIPE_FP32_ACTIVE) , how are these related to "DCGM_FI_PROF_PIPE_TENSOR_ACTIVE" metric?
What would be the ideal way to get the FLOPs (count) currently being worked by the GPU?

@nikkon-dev Any pointers will be greatly helpful? Thanks

@nikkon-dev @bmarchant , Gently ping on this question?

@krishh85,
There is no method to convert the utilization metrics and compare them to the theoretical FLOP numbers.
FP64_ACTIVE
The percentage of cycles in which the SM execution pipes are active in executing FP64 instructions. This does not include FP64 tensor instructions. Both GA100 and GH100 have high-speed FP64 pipes.

For GA100, DFMA, DADD, DMUL, and DSETP can be issued 0.25 instructions/cycle per SM sub-partition to the fp64 pipe.
For GH100, DFMA, DADD, DMUL, and DSETP can be issued at 0.5 instructions/cycle per SM sub-partition to the fp64 pipe.

The DFMA pipe and Tensor pipe share a dispatch port, so instructions cannot be issued to both pipes simultaneously.
There is no easy method to convert from pipe active to FP64 FLOPS. DFMA should have a weight of 2. DADD and DMUL should have a weight of 1. Many tools would not include DSETP (comparison) as an operation. Each instruction can execute on 0-32 instructions (due to thread active mask and predication mask). To provide an accurate FLOPs number, the per instruction weight and number of predicated actual instructions (write back the result) must be known.
The {PIPE}_ACTIVE metrics allow you to see what type of operations are performed and to what level of pipe activity is achieved. If a time period has a mix of operations types, it is difficult to quantify the efficiency. For example, if TC_ACTIVE is at 100%, then FP32_ACTIVE or FP16_ACTIVE will likely not be able to achieve more than 50%.
There is no weighted sum across pipes, which makes sense. In Nsight Compute, the primary method for profiling a workload is to look at the unit throughput (or Speed of Light) and determine what units are heavily utilized and what units are not utilized. The monitoring metrics do not cover the L1 and L2 memory subsystems, so the only sign of a memory-limited kernel is DRAM_ACTIVE.

@nikkon-dev A quick question before closing this. Are these metrics values in the range 0-1 or 0-100% , the documentation does not state that. Should all metrics that capture "Ratio of cycles" be considered 0-1 %?

repo: NVIDIA/DCGM


text:
Use Datum label field in the absence of a separate label database

For generic networks, if no separate label database is provided, DIGITS could default to using the scalar label from the image database (do we just need to add a label top to the data layer?). This would simplify the process of creating a "classification-like" model using the generic model path.

Closing as this is already working. I think this has been made possible by @lukeyeager's rework in #628.
To test this:

create a MNIST classification dataset using DIGITS
create an "other" dataset: in the image DB form fields, point to the train_db and val_db from the classification dataset you just created - don't provide label databases (we will use the labels from the image databases)
create a new "other" model: copy/paste the standard LeNet model (uncomment the num_output param of the ip2 layer to force 10 outputs)
now witness that the model trains correctly
test a few images from MNIST to make sure the model trained OK (you won't see results in the form of classifications but you will see that the last InnerProduct layer takes its maximum at the index of the class you're testing)

repo: NVIDIA/DIGITS


text:
Question about GPT topk sampling

It seem GPT topk sampling decoding strategy only support k = 1, 2, 4. I dont understand the design here. And is there anyway to use other value for GPT topk sampling decoding like k=50?

I think FT supports k = 50. Have you tried it?

I tried k=3 and got an error. I tracked the error here.

I used FT 3.1 by the way.

Please refer the latest code here https://github.com/NVIDIA/FasterTransformer/blob/main/fastertransformer/cuda/topk_kernels.cu#L762, which support at most 64.
The constraint is caused by the template. You can also add the k value you need directly.

Thanks! Directly adding CASE_K(50); solved my problem. But I'm still a little confused about the design here because I see you have another topk kernel called topK_kernelLauncher which accepts general K values.

It uses TopK_2<T> instead of TopK<T, MAX_K> so it has no constraint. So why set constraint for topK_sampling_kernel_kernelLauncher and not for topK_kernelLauncher.

General case would be slower.

Close this bug because it is inactivated. Feel free to re-open this issue if you still have any problem.

repo: NVIDIA/FasterTransformer


text:
support aten::index.Tensor

Description
aten::index.Tensor(Tensor self, Tensor?[] indices) -> (Tensor) is a complicated PyTorch function which can receive several indices. To focus on Video Swin Transformer, this version converter only supports one index. I will improve this converter in a future release.
Fixes #766
Type of change
Please delete options that are not relevant and/or add your own.

New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines of this project (You can use the linters)
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas and hacks
[x] I have made corresponding changes to the documentation
[x] I have added tests to verify my fix or my feature
[x] New and existing unit tests pass locally with my changes

Fixes #468

authors: ncomly-nvidia ruoqianguo

repo: NVIDIA/Torch-TensorRT