unicode-math and amsmath options

Description
unicode-math doesn't honor amsmath options such as intlimits
Check/indicate

[x] Relevant for XeTeX
[x] Relevant for LuaTeX
[x] Issue tracker has been searched for similar issues?
[x] https://tex.stackexchange.com/questions/457395/

Minimal example demonstrating the issue
\documentclass{article}
\usepackage[intlimits]{amsmath}
\usepackage{unicode-math}

\begin{document}
\[
\int_{a}^{b}
\]
\end{document}

Further details
amsmath takes its time in redefining every “big” operator so, for instance, \sum becomes \DOTSB\sum@\slimits@ and \int is<EMAIL_ADDRESS>Already \DOTSB and \DOTSI are quite important, but the main issue is the lack of \slimits@ and \ilimits@ that the options nosumlimits or intlimits redefine from their standard value of \displaylimits and \nolimits respectively.
unicode has the \addnolimits and \removenolimits undocumented feature, but it is awkward to apply.
I'm not sure whether the \DOTSx feature can really be added (the problem I see is that \int is translated into ∫ U+222B made math active), but I believe that honoring amsmath options as regards to the placement of limits should.

Good catch. Yes, I agree this should be supported.

Same as #482. Maybe, one of the issues should be closed. This one has more details.

Some extra detail from Reinhard Kotucha:

when I load unicode-math after amsmath, the amsmath option intlimits
has no effect any more.  The options sumlimits and namelimits still
work as expected.

 \documentclass{article}
 \usepackage[intlimits,sumlimits,namelimits]{amsmath}
 \usepackage{unicode-math}

 \begin{document}
   \[ \int_{0}^{1} \]
   \[ \sum_{i=0}^{1} \]
   \[ \lim_{x\to\infty} \]
 \end{document}

Is there any chance that this will be fixed??

Description
unicode-math doesn't honor amsmath options such as intlimits
Check/indicate
* [x]  Relevant for XeTeX

* [x]  Relevant for LuaTeX

* [x]  Issue tracker has been searched for similar issues?

* [x]  https://tex.stackexchange.com/questions/457395/

Minimal example demonstrating the issue
\documentclass{article}
\usepackage[intlimits]{amsmath}
\usepackage{unicode-math}

\begin{document}
\[
\int_{a}^{b}
\]
\end{document}

Further details
amsmath takes its time in redefining every “big” operator so, for instance, \sum becomes \DOTSB\sum@\slimits@ and \int is<EMAIL_ADDRESS>Already \DOTSB and \DOTSI are quite important, but the main issue is the lack of \slimits@ and \ilimits@ that the options nosumlimits or intlimits redefine from their standard value of \displaylimits and \nolimits respectively.
unicode has the \addnolimits and \removenolimits undocumented feature, but it is awkward to apply.
I'm not sure whether the \DOTSx feature can really be added (the problem I see is that \int is translated into ∫ U+222B made math active), but I believe that honoring amsmath options as regards to the placement of limits should.

Not only the \removenolimits is awkward to use, but it also doesn't work quite as amsmath's intlimits. The latter seems to make a change only in display math mode, inline looks the same. On the other hand, unicode-math with \removenolimits puts the limits much further away from the integral sign in inline math, too far in my opinion. I can't see any easy workaround, so I think it boosts the priority of this feature.

https://github.com/wspr/unicode-math/blob/d28e48e46392516bae43bd9cb15660f7037e47ac/um-code-setchar.dtx#L171
Replace \nolimits by amsmath internal \ilimits@ should work?


sops-nix fails when cross-compiling

I'm cross-compiling from x86_64-linux to armv6l-unknown-linux-gnueabihf:
builder for '/nix/store/16ac42gw5z54wz966pcr11a4cschc0y7-checked-manifest.json.drv' failed with exit code 126; last 1 log lines:
  /build/.attr-0l2nkwhif96f51f4amnlf414lhl4rv9vh8iffyp431v6s28gsr90: line 1: /nix/store/vaqv96g948bsj153vfxv03snlmpxj4f5-sops-install-secrets-0.0.1-armv6l-unknown-linux-gnueabihf/bin/sops-install-secrets: cannot execute binary file: Exec format error

Could be similar/related to https://github.com/NixOS/nixpkgs/issues/111251 ?

Could be similar/related to https://github.com/NixOS/nixpkgs/issues/111251 ?

Can you check if https://github.com/Mic92/sops-nix/pull/73 fixes this?

Can you check if https://github.com/Mic92/sops-nix/pull/73 fixes this?

@Mic92 when I try that:
builder for '/nix/store/9abb9yq9gx87lvx0xnq7gfg15d1fgyzq-sops-install-secrets-0.0.1-armv6l-unknown-linux-gnueabihf.drv' failed with exit code 1; last 10 log lines:
  go.mozilla.org/sops/v3/stores/json
  go.mozilla.org/sops/v3/stores/yaml
  github.com/blang/semver
  gopkg.in/urfave/cli.v1
  go.mozilla.org/sops/v3/version
  go.mozilla.org/sops/v3/cmd/sops/common
  go.mozilla.org/sops/v3/decrypt
  github.com/Mic92/sops-nix/pkgs/sops-install-secrets
  # github.com/Mic92/sops-nix/pkgs/sops-install-secrets
  pkgs/sops-install-secrets/main.go:265:14: constant<PHONE_NUMBER> overflows int32

This is a 32-bit issue now rather than a cross-compiling issue.

Builds on arm32 now: https://github.com/Mic92/sops-nix/pull/76


[Bug]: page 1265 "Data Exch. Setup Subform" Wrong Captions in the caption column

Describe the issue
In the page 1265 "Data Exch. Setup Subform", instead of the REC field, the page Caption is shown
and as a result and in all lines the caption columns are wrong.

Expected behavior

Steps to reproduce
Just run Currency Exchange Rate Services
Additional context
No response
I will provide a fix for a bug

[X] I will provide a fix for a bug

Sounds fair, but since the code you are referring to is in the BaseApp, you'd have to suggest and fix this code in the BaseApp contribution pilot: https://github.com/microsoft/businesscentralapps. For access to the pilot, please fill out the following form: https://forms.office.com/r/E9wyE5a58f.
This repository is only for extensibility requests or pull requests towards the 1st party Business Central apps.
Would you like me to move the issue to the contribution pilot for you?
IMPORTANT: Microsoft is not going to address the reported issue for you. You will have to get the issue approved, and then push a pull request with the suggested changes yourself. If you would like Microsoft to address the issue, please create a support request.

@JesperSchulz , I already have access to the pilot, can you move the issue there please?


[Event Request] OnAfterRecordChanged in Page 1351 "Posted Purch. Invoice - Update", 1353 "Posted Return Receipt - Update" and 1352 "Posted Return Shpt. - Update"

In the existing event trigger OnAfterRecordChanged we need the previouslay assign xPurchInvHeader, xReturnReceiptHeader and xReturnShipmentHeader as parameter:
old:
OnAfterRecordChanged(Rec, xRec, IsChanged);
new:
OnAfterRecordChanged(Rec, xReturnReceiptHeader , IsChanged);

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Move from unique_together to constraints

Fixes: #3146
This PR moves from unique_together to constraints, as proposed in #3146.
As I see it, here are two open questions:

[ ] Is the naming of the constraints important? They need to be globally unique, and are thus pretty verbose right now; we could also add a helper to autogenerate those, but maybe that’s also not really ideal. Any input would be appreciated.
[ ] It creates a lot of migrations. Because they were created in bulk, they all have autogenerated names. I usually opt for descriptive names, and would thus be willing to name them if that turns out to be a problem!

Cheers

Let's sit on this until v2.6 is released, just in case we end up needing to introduce a disruptive migration last minute.

Totally! I’ll rebase/merge if necessary.

Yeah, honestly I was also a little annoyed that I had to invent a naming scheme for a thing that doesn’t need a name!
I’ll sit on the naming for a while and think about it. Though if you have a consistent scheme in mind, I’m happy to work with it!
As per your edit, that was one of the open questions in my original PR!

Sounds reasonable to me. For the one @jeremystretch mentioned above that would lead to consoleport_name_device_key. Would we be okay with that?

Works for me. TIL there's a standard.
Just looking at the existing table in an old database I notice two formats:
"dcim_consoleport_cs_port_id_key" UNIQUE CONSTRAINT, btree (connected_endpoint_id)
"dcim_consoleport_device_id_name_293786b6_uniq" UNIQUE CONSTRAINT, btree (device_id, name)

Looks like Django switched from the bottom format to the top format.

Thanks for your feedback @lampwins and @jeremystretch!
I incorporated your feedback:

The unique constraints now have names that conform to the Postgres spec
The migrations are now called modernize_unique_constraints

Please let me know if you have any other feedback, questions, or suggestions!

Would it make sense to extend the class and have it auto generated the name based on the convention or is that just asking for trouble?

I needed to reorder the migrations as well, which is why the tests failed. It seems like all is well now again.

@DanSheps neat idea but it feels like tempting fate. Probably best to leave them manually defined.

Honestly, just figuring out the naming scheme has taken way too much effort for a net-zero change. Maybe we shouldn't worry about unique_together for now; the docs even say that it might be deprecated in the future, not that it will. I'm guessing that won't happen until UniqueConstraint is extended to support automatic naming conventions, which would remove most of the burden.
Sorry to put you through the wringer on this @hellerve. It's just how things shake out sometimes. :disappointed:

Hah, that’s totally fine. This ain’t my first OSS review rodeo, and some things just lead to yakshaving!
I think deferring this change is good, since I don’t see a lot of benefit in this either. Honestly, I just championed this because the issue was open, easy to work on, and open issues trigger my OCD.

Closing this for now


Added support for http-interop/http-middleware 0.5.0

Requires:

https://github.com/zendframework/zend-expressive-session/pull/2
https://github.com/zendframework/zend-expressive-flash/pull/1
to be merged and released before.
Then composer.json of the library should be updated to point released versions.

Closed in favour of #3


zh, en: add default value for --flush flag for v2.0.5

First-time contributors' checklist

[ ] I've signed Contributor License Agreement that's required for repo owners to accept my contribution.

What is changed, added, or deleted? (Required)

Which DM version(s) do your changes apply to? (Required)

[x] master (the latest development version)
[x] v2.0 (TiDB DM 2.0 versions)
[ ] v1.0 (TiDB DM 1.0 versions)

What is the related PR or file link(s)?

This PR is translated from:
Other reference link(s):

Do your changes match any of the following descriptions?

[ ] Delete files
[ ] Change aliases
[ ] Need modification after applied to another branch
[ ] Might cause conflicts after applied to another branch

/label needs-cherry-pick-release-2.0
/translation no-need
/status PTAL

/merge

/merge


3rd-party Gradle plug-ins may be the cause

Failed to resolve: junit
Open File
Folder /media/halove/work/demo/android-sunflower/app/build/generated/source/kaptKotlin/debug
Folder /media/halove/work/demo/android-sunflower/app/build/generated/source/kaptKotlin/release
3rd-party Gradle plug-ins may be the cause
my android studio:3.1.2

This project requires using the latest version of the Android Studio preview build, which can be downloaded from https://developer.android.com/studio/preview/.
Closing issue as I am unable to reproduce this on Android Studio 3.2 Beta 1.  Please comment again if you run into further issues.


[Bug] [dolphinscheduler-worker] Worker registry client start up error

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
use the mysql registry.found error like this
What you expected to happen
[WARN] 2022-10-14 16:31:15.088 +0800 org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext:[591] - [WorkflowInstance-0][TaskInstance-0] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'workerServer': Invocation of init method failed; nested exception is org.apache.dolphinscheduler.registry.api.RegistryException: Worker registry client start up error
Related cause: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskExecuteResultMessageSender': Unsatisfied dependency expressed through field 'workerRpcClient'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'workerRpcClient': Unsatisfied dependency expressed through field 'taskExecuteRunningAckProcessor'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskExecuteRunningAckProcessor': Unsatisfied dependency expressed through field 'messageRetryRunner'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'messageRetryRunner': Requested bean is currently in creation: Is there an unresolvable circular reference?
Related cause: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskExecuteRunningMessageSender': Unsatisfied dependency expressed through field 'workerRpcClient'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'workerRpcClient': Unsatisfied dependency expressed through field 'taskExecuteRunningAckProcessor'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskExecuteRunningAckProcessor': Unsatisfied dependency expressed through field 'messageRetryRunner'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'messageRetryRunner': Requested bean is currently in creation: Is there an unresolvable circular reference?
Related cause: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskRejectMessageSender': Unsatisfied dependency expressed through field 'workerRpcClient'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'workerRpcClient': Unsatisfied dependency expressed through field 'taskExecuteRunningAckProcessor'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskExecuteRunningAckProcessor': Unsatisfied dependency expressed through field 'messageRetryRunner'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'messageRetryRunner': Requested bean is currently in creation: Is there an unresolvable circular reference?
[WARN] 2022-10-14 16:31:15.089 +0800 org.apache.dolphinscheduler.common.model.BaseHeartBeatTask:[69] - [WorkflowInstance-0][TaskInstance-0] - WorkerHeartBeatTask task finished
[INFO] 2022-10-14 16:31:15.089 +0800 org.apache.dolphinscheduler.plugin.registry.mysql.MysqlRegistry:[189] - [WorkflowInstance-0][TaskInstance-0] - Closing Mysql Registry...
[INFO] 2022-10-14 16:31:15.090 +0800 com.zaxxer.hikari.HikariDataSource:[350] - [WorkflowInstance-0][TaskInstance-0] - MysqlRegistryDataSourcePool - Shutdown initiated...
[INFO] 2022-10-14 16:31:15.109 +0800 com.zaxxer.hikari.HikariDataSource:[352] - [WorkflowInstance-0][TaskInstance-0] - MysqlRegistryDataSourcePool - Shutdown completed.
[INFO] 2022-10-14 16:31:15.110 +0800 org.apache.dolphinscheduler.plugin.registry.mysql.MysqlRegistry:[199] - [WorkflowInstance-0][TaskInstance-0] - Closed Mysql Registry...
[INFO] 2022-10-14 16:31:15.111 +0800 org.apache.dolphinscheduler.server.worker.registry.WorkerRegistryClient:[113] - [WorkflowInstance-0][TaskInstance-0] - Worker registry client closed
[INFO] 2022-10-14 16:31:15.112 +0800 org.apache.dolphinscheduler.server.worker.rpc.WorkerRpcServer:[98] - [WorkflowInstance-0][TaskInstance-0] - Worker rpc server closing
[INFO] 2022-10-14 16:31:15.114 +0800 org.apache.dolphinscheduler.remote.NettyRemotingServer:[212] - [WorkflowInstance-0][TaskInstance-0] - netty server closed
[INFO] 2022-10-14 16:31:15.115 +0800 org.apache.dolphinscheduler.server.worker.rpc.WorkerRpcServer:[100] - [WorkflowInstance-0][TaskInstance-0] - Worker rpc server closed
[INFO] 2022-10-14 16:31:15.115 +0800 org.apache.dolphinscheduler.server.worker.rpc.WorkerRpcClient:[71] - [WorkflowInstance-0][TaskInstance-0] - Worker rpc client closing
[INFO] 2022-10-14 16:31:15.118 +0800 org.apache.dolphinscheduler.remote.NettyRemotingClient:[390] - [WorkflowInstance-0][TaskInstance-0] - netty client closed
[INFO] 2022-10-14 16:31:15.118 +0800 org.apache.dolphinscheduler.server.worker.rpc.WorkerRpcClient:[73] - [WorkflowInstance-0][TaskInstance-0] - Worker rpc client closed
[INFO] 2022-10-14 16:31:15.118 +0800 org.apache.dolphinscheduler.plugin.registry.mysql.MysqlRegistry:[189] - [WorkflowInstance-0][TaskInstance-0] - Closing Mysql Registry...
[INFO] 2022-10-14 16:31:15.118 +0800 org.apache.dolphinscheduler.plugin.registry.mysql.MysqlRegistry:[199] - [WorkflowInstance-0][TaskInstance-0] - Closed Mysql Registry...
[WARN] 2022-10-14 16:31:15.119 +0800 org.apache.dolphinscheduler.service.alert.AlertClientService:[76] - [WorkflowInstance-0][TaskInstance-0] - Alert client is already closed
[WARN] 2022-10-14 16:31:15.121 +0800 org.springframework.beans.factory.support.DisposableBeanAdapter:[248] - [WorkflowInstance-0][TaskInstance-0] - Invocation of close method failed on bean with name 'springApplicationContext': org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'applicationAvailability': Singleton bean creation not allowed while singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
[INFO] 2022-10-14 16:31:15.125 +0800 org.eclipse.jetty.server.session:[149] - [WorkflowInstance-0][TaskInstance-0] - node0 Stopped scavenging
[INFO] 2022-10-14 16:31:15.126 +0800 org.eclipse.jetty.server.handler.ContextHandler:[1159] - [WorkflowInstance-0][TaskInstance-0] - Stopped o.s.b.w.e.j.JettyEmbeddedWebAppContext@685e6a68{application,/,[file:///tmp/jetty-docbase.1235.4011951258952071028/],STOPPED}
[INFO] 2022-10-14 16:31:15.143 +0800 org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener:[136] - [WorkflowInstance-0][TaskInstance-0] -
How to reproduce
at the Cluster mode
Anything else
No response
Version
3.1.x
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[ ] I agree to follow this project's Code of Conduct

version is 3.1.0
this is the all error messages
[
1.txt
](url)
thanks

because your registry is mysql, the worker will register with the registry when it starts, but the registration fails and an error is reported in writing, probably because you have not configured zk, and then ds will choose the current registry to register

because your registry is mysql, and the worker registers with the registry when it starts, but the registration fails and an error is reported. It is recommended that you configure the center to select zk

because your registry is mysql, and the worker registers with the registry when it starts, but the registration fails and an error is reported. It is recommended that you configure the center to select zk

yes，the mysql registry is already release,so i want use the mysql registry

Please confirm if this issue exists in 30x and dev.

Please confirm if this issue exists in 30x and dev.

The dev environment is OK


Hide Title if user has no access to it

Hello,
After LogOut, the user are still able to see the path of the page he/she is trying to access at the Breadcrumb and the Title of the page. Not exactly a bug, and I know it's the default behavior of DokuWiki (as far as I've seen into other templates too), but I believe it should be great to hide the Title of page if user isn't authenticated and isn't logged in into DokuWiki while trying to access a namespace he/she has no access to. Not sure if it's possible though.

Sorry but the feature you are asking for is beyond the scope of this template. You should ask to the Dokuwiki author.
However, you can hide breadcrumbs when you are logged out with css. When you are logged in, div#dokuwiki__site has loggedIn class. so adding the style below will hide breadcrumbs when you are logged out.
#dokuwiki__site:not(.loggedIn) .breadcrumbs
{
display: none;
}

Thank you!


Can't install Puphpeteer

I tried to install Puphpeteer using composer require nesk/puphpeteer but I get an error:
Using version ^1.6 for nesk/puphpeteer
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Restricting packages listed in "symfony/symfony" to "5.0.*"
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - nesk/rialto 1.3.0 requires symfony/process ^3.3|^4.0 -> no matching package found.
    - nesk/rialto 1.2.1 requires symfony/process ^3.3|^4.0 -> no matching package found.
    - nesk/rialto 1.2.0 requires symfony/process ^3.3|^4.0 -> no matching package found.
    - nesk/puphpeteer 1.6.0 requires nesk/rialto ^1.2.0 -> satisfiable by nesk/rialto[1.2.0, 1.2.1, 1.3.0].
    - Installation request for nesk/puphpeteer ^1.6 -> satisfiable by nesk/puphpeteer[1.6.0].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Installation failed, reverting ./composer.json to its original content.

Any updates on getting this to work with symfony/process 5?

Fixed in nesk/rialto v1.4.0


NTR: zinc:bicarbonate symporter activity and cadmium:bicarbonate symporter activity

Hi,
could you please consider creating the above mentioned terms
Definition :
Enables the transfer of a solute or solutes from one side of a membrane to the other according to the reaction: Cd2+(out) + HCO3-(out) = Cd2+(in) + HCO3-(in).
OR
Zn2+(out) + HCO3-(out) = Zn2+(in) + HCO3-(in).
as child of a new term that would be solute:bicarbonate symporter activity, itself a child of GO:0015294 solute:cation symporter activity and GO:0015106 bicarbonate transmembrane transporter activity.
Best, Lionel

Hi,
related to the same ticket and same protein, PubMed=27166256, showed that Slc39a8 is a transporter allowing the following symport :
Zn2+(out) + HCO3-(out) + selenite = Zn2+(in) + HCO3-(in) +selenite.
Could you please create a GO term for this molecular function?
Alternatively, we could create a term for selenite symporter activity, but that is not coupled to proton symport as described by  GO:0097079 selenite:proton symporter activity
I do not know what would be the best.
Cheers, Lionel

@lbreuza all all these functions described in PubMed=27166256?
How specific is the transporter for the cation ? Perhaps we indeed need selenite:cation antiporter activity ?
Thanks, Pascale

@pgaudet There are several papers including PMID:18037372 that describe the symporter activity of SLC39A8.
You can find them already in P2GO for that gene.

Can transport several cations including Mg2+, Fe2+, Hg2+ and Cd2+. So not very specific. However, the symport coupled to selenite and bicarbonate has only been shown for Zn2+.

Hi,
I am not sure about the status of this ticket. I have some pending annotations and would like to know what to do with them. Best, Lionel

Holidays;

@lbreuza Are you sure this is a symporter ? I see in the paper that the Zn transport is dependent on zinc and bicarbonate but I don't see that they tested where these other ions end up ?
Could it be an antiporter ? Or just be more efficient in the presence of those ions ?

Hi @pgaudet,
here is the function I wrote from different supporting evidence: " Functions as an energy-dependent symporter, transporting through the membranes an electroneutral complex composed of a divalent metal cation, a bicarbonate and a selenite anion or yet a metal cation and two bicarbonate anions (PubMed:27166256, PubMed:31699897)".
Cheers, Lionel

'cadmium has no known biological function in higher organisms, a cadmium-dependent carbonic anhydrase has been found in marine diatoms.' From https://en.wikipedia.org/wiki/Cadmium
Is Cd transport relevant biologically ? Or has it just been tested ?

@lbreuza for selenite, is selenite being transported in the same direction as the other ions ? 'Zn2+(out) + HCO3-(out) + selenite = Zn2+(in) + HCO3-(in) +selenite.'

Never mind - from the paper it seems to be a symporter.

+[Term]
+id: GO:0140410
+name: solute:bicarbonate symporter activity
+namespace: molecular_function
+def: "Enables the transfer of a solute or solutes from one side of a membrane to the other according to the reaction: solute(out) + HCO3-(out) = solute(in) + HCO3-(in)." [PMID:27166256]
+comment: Created new term from request: https://github.com/geneontology/go-ontology/issues/18345.
+intersection_of: GO:0015293 ! symporter activity
+intersection_of: transports_or_maintains_localization_of CHEBI:17544 ! hydrogencarbonate
+intersection_of: transports_or_maintains_localization_of CHEBI:24431 ! chemical entity
+created_by: pg
+creation_date: 2020-01-07T16:58:49Z
+
+[Term]
+id: GO:0140412
+name: zinc:bicarbonate symporter activity
+namespace: molecular_function
+def: "Enables the transfer of a solute or solutes from one side of a membrane to the other according to the reaction: zinc(out) + HCO3-(out) = zinc(in) + HCO3-(in)." [PMID:27166256]
+comment: Created new term from request: https://github.com/geneontology/go-ontology/issues/18345.
+intersection_of: GO:0015293 ! symporter activity
+intersection_of: transports_or_maintains_localization_of CHEBI:17544 ! hydrogencarbonate
+intersection_of: transports_or_maintains_localization_of CHEBI:63056 ! zinc cation
+created_by: pg
+creation_date: 2020-01-07T18:43:02Z
+
+[Term]
+id: GO:0140413
+name: zinc:bicarbonate:selenite symporter activity
+namespace: Enables the transfer of a solute or solutes from one side of a membrane to the other according to the reaction: zinc(out) + HCO3-(out) + HO3Se-(out) = zinc(in) + HCO3-(in) + HO3Se-(out). {xref="PMID:27166256"}
+namespace: molecular_function
+comment: Created new term from request: https://github.com/geneontology/go-ontology/issues/18345.
+intersection_of: GO:0015293 ! symporter activity
+intersection_of: transports_or_maintains_localization_of CHEBI:17544 ! hydrogencarbonate
+intersection_of: transports_or_maintains_localization_of CHEBI:18170 ! selenic acid
+intersection_of: transports_or_maintains_localization_of CHEBI:63056 ! zinc cation
+created_by: pg
+creation_date: 2020-01-07T18:58:12Z

Hi Pascale,
concerning Cadmium, Cd is a toxic and carcinogenic nonessential metal (1), which can enter the body through the intestine, skin, and lung and accumulates in the kidney (1–3). The level of Cd in the environment has risen with advances in industrialization, and the role of Cd in human disease is of increasing concern. The mechanisms of Cd toxicity are poorly understood, although it is known that Cd exerts its effects intracellularly, and there are polypeptides such as metallothionein (4) and reduced glutathione (5) that bind Cd and afford protection.
There is also a mouse model that shows resistance to Cd toxicity that has been used to identify the gene involved in.
They tested its transport because it is relevant in terms of physiology (environment) and not as any positive cations. This is why I thought we might create a term for this transport but I do not know about the policies of the Consortium with respect to this.
Thanks for creating the other terms.

I think Cd (like rubidium and others) is 'hijacking' a transporter that transports similar substances, but the cell has not bona fide Cd transporter.
This is considered outside the scope of GO.
Thanks, Pascale

"Hijacking" here seems to me like too narrow a view of an organism's short term responses to environmental stresses and of a population's long-term evolutionary responses to changing environments. Agreed, life downwind of a smelter may not fit our view of a normal stress or environment but it's also not the case that environmental cadmium or rubidium levels were the integer zero in our state of nature, and the otherwise edible plants that take up minerals like cadmium and concentrate them to human-toxic levels are not new.

Right - response to Cadmium would be a 'normal' function, and certainly exporting it would also make sense - and it would make sense to annotate the protein to something like 'xenobiotic detoxification by transmembrane export across the plasma membrane' (obviously Cd is not a xenobiotic, but transporting it out would detoxify it).
But as far as I can tell from the paper this gene product does not export Cd, it 'accidentally' imports it. Is this right ?

Yes @pgaudet. As far as I understand cadmium is accidentally symported and toxic for cells. Some mice strain that express less transporter are less susceptible to Cd toxicity. Not easy to draw a line between what is physiological and what is not here.
Lionel

GO:0140410  solute:bicarbonate symporter activity
should be labelled monoatomic cation:bicarbonate symporter activity
this is more accurate for the children it's trying to group


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-27-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3898

Questions ?
Please refer to the Backport tool documentation


CVODES

Summary:
replace cvode integrator with codes. So remove cvode and replace functionality by cvodes.
Description:
The current cvode integrator uses a coupled ode system in order to obtain sensitivities of an ODE system. This is handled in a fully integrated way by cvodes. Benefits of using cvodes:

always faster than cvode+coupled
greater robustness (in particular for large ODE systems)
less code to maintain as more work is done from library
Cvodes supports adjoint sensitivity analysis which can be included at a later stage; this allows to calculate directly the sensitivities of a cost function wrt to parameters which is useful if we only need the sensitivities of a single state which enters the likelihood.

Reproducible Steps:
Bad performance with big ODE systems. For example, the PERC model. Other big models are equally suitable to show slow performance of the cvode/coupled system.
Current Output:
Some ODE systems make the cvode/coupled integrator very slow.
Expected Output:
Large ODE systems should not slow down the integrator.
Additional Information:
This is a large patch and we may just use this as a basis to split into smaller bits and pieces. This patch introduces also the ode_model object which can be used to enable analytic Jacobians for ODE systems via template specialization. Moreover, the decoupling operation is split out of the coupled_ode system object. This patch can form the basis for a nice refactoring of the coupled_ode_system.
Current Version:
None. Only the current develop version of math

I think Michael's going to have to chime in on the math and algorithms.
Is that PERC model available somewhere we can use to benchmark?  Does anybody know if we can distribute the data?  Otherwise, maybe Michael has some ideas for performance tests?
I'm more than happy to help out with the nitpicky code integration details.

Hi!
I am asking Frederic about the PERC model right now, will let you know once I have feedback from him. I can provide other large (published) models which show the same problems when being solved with cvode+coupled instead of CVODES.
In case we want to merge in smaller steps, then we could consider merging the  current branch feature-262-CVODES. Right now all I have done is to replace CVODE with CVODES. Since CVODES is 100% compatible to CVODE, there is no code change right now to the current CVODE+coupled code and all tests do pass!
In case we want to swap out CVODE for CVODES now, then I would branch of this branch in order to include the really big change this switch brings.
Just let me know what is best here... otherwise I proceed an populate this feature branch with my code.

Sebastian, thanks for asking Frederic about it.

For those that are interested in it, the data, Frederic's original
model, and my replication efforts are on a private repo:
https://github.com/gelman/perc. It's private so the data doesn't float out
until we know what the restrictions are. Part of the data is available
through GNU mcsim.
Frederic's original model doesn't fit. That's why I've been trying to
break it down. I don't think using the original model as a benchmark is
appropriate since it's clear that we haven't figured it out and we may be
timing something that isn't relevant to typical useage.

On Fri, Mar 18, 2016 at 9:39 AM, wds15<EMAIL_ADDRESS>wrote:

Hi!
I am asking Frederic about the PERC model right now, will let you know
once I have feedback from him. I can provide other large (published) models
which show the same problems when being solved with cvode+coupled instead
of CVODES.
In case we want to merge in smaller steps, then we could consider merging
the current branch feature-262-CVODES. Right now all I have done is to
replace CVODE with CVODES. Since CVODES is 100% compatible to CVODE, there
is no code change right now to the current CVODE+coupled code and all tests
do pass!
In case we want to swap out CVODE for CVODES now, then I would branch of
this branch in order to include the really big change this switch brings.
Just let me know what is best here... otherwise I proceed an populate this
feature branch with my code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/stan-dev/math/issues/262#issuecomment-198364021

for the purpose of an ODE benchmark, we don't need the data. It would be nice, yes; but if we only are out for the ODE performance, then the ODE and a parameter set are sufficient. And as I said, if we don't trust the PERC model, I can provide other (published) examples. Let me prepare one of those.
I take that we do this in a single go (or cherry pick later smaller part of this branch). Great.

Thanks. Please provide another example until we can get the perc model
working.
I didn't understand your last comment.
On Fri, Mar 18, 2016 at 9:53 AM, wds15<EMAIL_ADDRESS>wrote:

for the purpose of an ODE benchmark, we don't need the data. It would be
nice, yes; but if we only are out for the ODE performance, then the ODE and
a parameter set are sufficient. And as I said, if we don't trust the PERC
model, I can provide other (published) examples. Let me prepare one of
those.
I take that we do this in a single go (or cherry pick later smaller part
of this branch). Great.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/stan-dev/math/issues/262#issuecomment-198371626

I think I found a great example: The Hornberg model is described in the reference DOI: 10.1111/j.1432-1033.2004.04404.x is a great case. Unfortunately the paper itself is paywalled, but the model itself is freely available here (this link is right next to the abstract):
http://jjj.biochem.sun.ac.za/database/hornberg/index.html
This model has 8 states+18 parameters which describe a system of reactions with a number of michaelis-menten kinetics. This is a large, but very typical use-case I suppose.
The model one can download includes the equations, initial values and parameters to simulate. I suggest to put this into an executable test which I propose to put on an independent branch such that we can merge this into develop eventually and also merge this into the CVODES branch. I hope that makes sense.

Sounds great.

On Mar 19, 2016, at 10:15 AM, wds15<EMAIL_ADDRESS>wrote:
I think I found a great example: The Hornberg model is described in the reference DOI: 10.1111/j.1432-1033.2004.04404.x is a great case. Unfortunately the paper itself is paywalled, but the model itself is freely available here (this link is right next to the abstract):
http://jjj.biochem.sun.ac.za/database/hornberg/index.html
This model has 8 states+18 parameters which describe a system of reactions with a number of michaelis-menten kinetics. This is a large, but very typical use-case I suppose.
The model one can download includes the equations, initial values and parameters to simulate. I suggest to put this into an executable test which I propose to put on an independent branch such that we can merge this into develop eventually and also merge this into the CVODES branch. I hope that makes sense.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

Ok, here it goes!
The stiff stress test is taking ages with the old cvode implementation. The same test is now also included in the CVODES branch which I just pushed to the repository. The test can be triggered with
/runTests.py test/unit/math/rev/arr/functor/integrate_ode_perf_test.cpp
The CVODES branch currently passes all integrated_ode_code* tests. However, the coupled_ode_system_code* tests do NOT pass at the moment as I have replaced the coupled_ode_system_cvode with the cvodes_integrator object. From what I can see, it would make sense to change the coupled_ode_system_cvode tests such that they test instead the cvodes_integrator. I am happy to do that.
However, I guess first we should settle on the design of things as I did change a few things. Most importantly, I do no anymore use a shifted system when initials vary. Moreover, the code I supply can serve as a refactoring base for the odeint based integrator.
Finally, I am also providing another hornberg test which demonstrates how one can use partial template specialization in order to provide analytic Jacobians.

I have ported all cvode related tests to the new code. I renamed in the folder test/unit/math/rev/arr/functor/

coupled_ode_system_cvode_prim_test.cpp to cvodes_integrator_prim_test.cpp
coupled_ode_system_cvode_rev_test.cpp to cvodes_integrator_rev_test.cpp

and ported each test to the slightly updated logic. I suppose these two files are a good reference to demonstrate how the cvodes integrator works.
The source code contains at the moment here and there still some comments to make it easier to grasp what changed how. For the final merge we can delete a number of those comments.
Moreover, I would like to enable the non-stiff solver from cvode such that I would propose to add a further "solver" argument to the integrate_ode_cvode function. The code is prepared for that, but I am not sure if you agree on this.

That all sounds great.  @betanalpha, can you weigh in on this?
I'm a bit out of my depth with the ODEs and any potential
gotchas.
@wds15:  That all sounds great!  When you say you don't use a
shifted system, do you compute the same function?  If so,
it shouldn't be a problem.
@betanalpha: can you take a look at this and weigh in on any
potential issues?

Bob

On Mar 19, 2016, at 3:33 PM, wds15<EMAIL_ADDRESS>wrote:
Ok, here it goes!
The stiff stress test is taking ages with the old cvode implementation. The same test is now also included in the CVODES branch which I just pushed to the repository. The test can be triggered with
/runTests.py test/unit/math/rev/arr/functor/integrate_ode_perf_test.cpp
The CVODES branch currently passes all integrated_ode_code* tests. However, the coupled_ode_system_code* tests do NOT pass at the moment as I have replaced the coupled_ode_system_cvode with the cvodes_integrator object. From what I can see, it would make sense to change the coupled_ode_system_cvode tests such that they test instead the cvodes_integrator. I am happy to do that.
However, I guess first we should settle on the design of things as I did change a few things. Most importantly, I do no anymore use a shifted system when initials vary. Moreover, the code I supply can serve as a refactoring base for the odeint based integrator.
Finally, I am also providing another hornberg test which demonstrates how one can use partial template specialization in order to provide analytic Jacobians.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

We can add a new function, but we don't want to break the
old one.  If the new argument is just going to be a string,
then I'd suggest rolling it into the function name, like:
integrate_ode_cvodes(...);
and then our existing
inegrate_ode(...)
can delegate to one of the versions.  From the semantic side
of the parser, it's almost as easy to pull it out of the name
as out of an argument.
Others may have better ideas for naming.
We can deprecate the old function and get rid of it in
the future.

I am definetly calculating the very same function, of course. In fact, all the dy_dt's are exactly the same, the only difference is how the initials are set. The test file cvodes_integrator_rev_test.cpp shows how this differs.
I am proposing to leave the integrate_ode function just as it is. All I am suggesting is to change the function signature of
integrate_ode_cvode
, i.e. I propose to add a further "solver" argument which I suggest to be an integer. To my knowledge the function integrate_ode_cvode was never released, but only "lived" on the develop branch. This is why I thought changing the signature at this stage would be ok. Specifically I would like to have the solver definitions to be

0 = non-stiff (Adams-Moulton)
1 = stiff (BDF)
2 = stiff (BDF) with STaLD

The STaLD algorithm is a stability limit detection algorithm for BDF. It does cost you 5-7% performance and is in rare cases (according to the documentation of CVODES) needed in order to guarantee numerical stability of the BDF method. In case I manage to figure out how to compile CVODES with the MKL, then we could add another stiff solver which uses the MKL - given this is noticeable in speedup and can be easily deployed.
To proceed, should I kick off a pull request?

I think we need to step back and more carefully understand some underlying issues.

Firstly, I don’t trust anything with abs/rel sensitivities any higher than O(10^{-8}).
When I was doing testing I kept getting really inaccurate, as in O(10^{-3)) absolute
error, solutions with higher solution sensitivities, even in simple models.  These
large errors can invalidate everything we do and so we have to be sure that we’re
getting accurate solutions (i.e. the Metropolis correction does not fix this as it
biases the Metropolis correction itself).  This carries over to all of the switching
between algorithms — there is no trade off on accuracy vs performance, there
is only performance conditioned on sufficient accuracy.

Why is CVODES supposedly so much faster than CVODE with our AD computing
the Jacobian?  I’m not even sure how CVODES can compute sensitivities given
the general complexity of our language — are we sure that it’s only been testing
on simple models that just use simple algebraic calculations?  And even if it can,
how is it so much faster than our AD?  I can see indirection being slow, or even
CVODES being able to ensure better memory locality, but for that to lead to such
a speed up is suspicious to me.

I’m still hesitant about spending too much effort on having self-implementable
gradients.  Sebastian might find this useful but most of our users are using Stan
exactly because they don’t want to deal with such complications.  If there are
such speed ups possible in typical PK/PD models then it’s much more useful
to implement exact gradients for various systems internally as prepackaged
ODE functors written in C++.

On Mar 20, 2016, at 6:47 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

That all sounds great. @betanalpha, can you weigh in on this?
I'm a bit out of my depth with the ODEs and any potential
gotchas.
@wds15: That all sounds great! When you say you don't use a
shifted system, do you compute the same function? If so,
it shouldn't be a problem.
@betanalpha: can you take a look at this and weigh in on any
potential issues?

Bob

On Mar 19, 2016, at 3:33 PM, wds15<EMAIL_ADDRESS>wrote:
Ok, here it goes!
The stiff stress test is taking ages with the old cvode implementation. The same test is now also included in the CVODES branch which I just pushed to the repository. The test can be triggered with
/runTests.py test/unit/math/rev/arr/functor/integrate_ode_perf_test.cpp
The CVODES branch currently passes all integrated_ode_code* tests. However, the coupled_ode_system_code* tests do NOT pass at the moment as I have replaced the coupled_ode_system_cvode with the cvodes_integrator object. From what I can see, it would make sense to change the coupled_ode_system_cvode tests such that they test instead the cvodes_integrator. I am happy to do that.
However, I guess first we should settle on the design of things as I did change a few things. Most importantly, I do no anymore use a shifted system when initials vary. Moreover, the code I supply can serve as a refactoring base for the odeint based integrator.
Finally, I am also providing another hornberg test which demonstrates how one can use partial template specialization in order to provide analytic Jacobians.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Hi!
Let me try to answer:

To my understanding the solution from CVODES will be better behaved in terms of accuracy as I do not use a shifted system and hence the abs+rel tolerances are applied to the unshifted values we are interested in. In fact, I have programmed a test which compares ODE solutions against an analytic solution. The tests I have done show accuracy within 1e-5, I haven't tested higher accuracy.

I can only speculate what breaks the performance of cvode+coupled system. My guess would be that it has problems finding a suitable step-size. Wrt to CVODES: The implementation uses AD from Stan to get all needed Jacobian information. Nothing changes in this regard, there is really no difference. The main difference comes from how the mathematical problem is approached within CVODES. That is, CVODES takes advantage of the specific structure of the problem. As you have proven, the Jacobian of the coupled system has a special structure. The difference between cvode+coupled and CVODES is mainly that CVODES first solves the main (base) system and then solves for the sensitivites (once the main solution has converged). Apparently this works out better than solving all at once.

user-supplied gradients would be a great thing from my perspective, but we can discuss this later. I agree that it is tedious to code them and most users would not do it. In fact, the example I included uses a Jacobian which was generated automatically in symbolic form for me by a script. So if we provide such an option, then we certainly want to point out automatic approaches to generate the symbolic Jacobian. Of course, pre-coded ODE systems as part of the Stan library would be another good option.

To my understanding the solution from CVODES will be better behaved in terms of accuracy as I do not use a shifted system and hence the abs+rel tolerances are applied to the unshifted values we are interested in. In fact, I have programmed a test which compares ODE solutions against an analytic solution. The tests I have done show accuracy within 1e-5, I haven't tested higher accuracy.

Yeah, that’s what I saw in simple problems.  And that’s just not good enough for our
purposes — that’s a large enough bias to completely mess up the accuracy of the
MCMC estimators and we have no way of correcting it.

I can only speculate what breaks the performance of cvode+coupled system. My guess would be that it has problems finding a suitable step-size. Wrt to CVODES: The implementation uses AD from Stan to get all needed Jacobian information. Nothing changes in this regard, there is really no difference. The main difference comes from how the mathematical problem is approached within CVODES. That is, CVODES takes advantage of the specific structure of the problem. As you have proven, the Jacobian of the coupled system has a special structure. The difference between cvode+coupled and CVODES is mainly that CVODES first solves the main (base) system and then solves for the sensitivites (once the main solution has converged). Apparently this works out better than solving all at once.

Does it take in a Jacobian callback or calculate it internally using finite diffs?

user-supplied gradients would be a great thing from my perspective, but we can discuss this later. I agree that it is tedious to code them and most users would not do it. In fact, the example I included uses a Jacobian which was generated automatically in symbolic form for me by a script. So if we provide such an option, then we certainly want to point out automatic approaches to generate the symbolic Jacobian. Of course, pre-coded ODE systems as part of the Stan library would be another good option.

I think right now we don’t want to burden ourselves with additional maintenance of
trying to expose such a feature.  In other words, this should be saved for last.

The CVODES library talks about introducing scaling factors for the senstivities in order to improve accuracy. In short, it is useful to provide "order-of-magnitude" information. This is what the manual says. Since the sensitivity wrt to a parameter p is related to the value of the parameter itself, we could try to look into this. I haven't pushed CVODES to more than 1E-5, let me try.

To answer your question: Of course, CVODES uses callbacks in order to get Jacobian information from Stan using AD. There is no finite difference being done here.

.. and to add to my previous answer: CVODES is CVODE with Sensitivity support. So this is an extension to CVODE which specifically adresses sensitivity stuff. There has to be a reason why sundials provides a specific software suite for ODE+Sensitivity problems and the ODE stiff benchmark is an example of this. So, yes, using CVODES gives such a large speedup not only due to better memory locality, but mostly due to better algorithms to solve the ODE+sensitivity problem.

The CVODES library talks about introducing scaling factors for the senstivities in order to improve accuracy. In short, it is useful to provide "order-of-magnitude" information. This is what the manual says. Since the sensitivity wrt to a parameter p is related to the value of the parameter itself, we could try to look into this. I haven't pushed CVODES to more than 1E-5, let me try.

Let's be careful to differentiate solver sensitivities (which control the accuracy of numerical solutions)
and the ODE sensitivities (which are the derivatives that we want).
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators.  My intuition is that 1e-5 is too large,
which is the typical error that the nominal settings in the original Boost integrator and CVODE
were giving,

To answer your question: Of course, CVODES uses callbacks in order to get Jacobian information from Stan using AD. There is no finite difference being done here.

.. and to add to my previous answer: CVODES is CVODE with Sensitivity support. So this is an extension to CVODE which specifically adresses sensitivity stuff. There has to be a reason why sundials provides a specific software suite for ODE+Sensitivity problems and the ODE stiff benchmark is an example of this. So, yes, using CVODES gives such a large speedup not only due to better memory locality, but mostly due to better algorithms to solve the ODE+sensitivity problem.

Yeah I get the difference between CVODE and CVODES now — CVODES is using a different
numerical solver and not just trying to compute everything internally.  So we have to pass in
a Jacobian for CVODES to define the sensitivity solutions, but what about the Jacobian of
the sensitivity system?  The one that requires second-order derivatives?  This is the
“banded Jacobian” in the current implementation of the CVODE solver in Stan.

Well, maybe we look into the cvodes user manual, they talk about accuracy considerations; as I say, in order to improve the accuracy of the ODE sensitivities, they recommend to define scaling factors. The basic observation here being that the accuracy of df/dp is related to p.

From what I understand from the cvodes user manual is that they use a "modified" Newton iteration to solve the sensitivity system. This modified Newton iteration reuses the Jacobian of the base system. So they take advantage of the special structure and reuse Jacobian information as much as possible. From reading the user guide I understand that they internally setup such a banded system and solve that. This is all detailed in the user manual of cvodes, please have a look at their mathematical considerations section.

No, no, no.  I’m saying that the absolute and relative sensitivities that specify
the accuracy of the numerical solutions to f (and then to the numerical solutions
of the df/dp as they’re solved in a similar fashion) which are currently default
are not sufficient for statistical use.  We need to tune the solvers to achieve
higher accuracy by default and test for this higher accuracy in the unit tests.
On Mar 21, 2016, at 12:49 PM, wds15<EMAIL_ADDRESS>wrote:

Well, maybe we look into the cvodes user manual, they talk about accuracy considerations; as I say, in order to improve the accuracy of the ODE sensitivities, they recommend to define scaling factors. The basic observation here being that the accuracy of df/dp is related to p.

Well, CVODES offers more control over the absolute and relative tolerances for the sensitivities. In fact, if you want to, you can set these for each parameter sensitivity separatley. So CVODES should let us tune things to higher accuracy.
Although, I have to say that I don't yet fully understand why such high accuracy sensitivites are needed. Do you have examples somewhere which show what goes wrong? I mean, I am getting very good inferences from Stan when using ODEs. Maybe things are not ultra-precise, but in my applications the accuracy is sufficient enough. At least from what I can say.
But to come back to CVODES: The implementation passes all tests which were written for CVODE; what else is needed to merge this? The increased accuracy story is separate to this and should be dealt with in another issue+pull request, no?

I AM NOT TALKING ABOUT JUST THE ACCURACY OF THE SENSITIVITIES.
I am suspicious of much of our ODE tests because they rely on defaults that
lead to numerical state solutions (and sensitivities, but ignore them as apparently
they’re just confusing things) which quite large errors.  We have no way to correct
these errors, they consequently propagate through our entire system and bias
the MCMC estimators and we have NO IDEA HOW LARGE THIS EFFECT MIGHT
BE.  Our standard should not be “looks good enough by eye in this problem where
I don’t know what the correct mean and variances are” but rather “we can constrain
the absolute error well enough that our implementation is robust to almost all use
cases”.
Would everyone be happy if our exp or log implementations had absolute accuracy
of only 10^{-3} or 10^{-5}?
This point is relevant to this and the other PR because they are based on
performance, which requires us defining what our threshold for accuracy should be.
I tried to ameliorate this a bit in the CVODE implementation by dropping the abs/rel
defaults to 1e-10 which gave about 1e-8 errors.  But if we’re going to start comparing
different solvers to the point of advocating one over another then we need to define
what accuracy we want to require.
On Mar 21, 2016, at 1:39 PM, wds15<EMAIL_ADDRESS>wrote:

Well, CVODES offers more control over the absolute and relative tolerances for the sensitivities. In fact, if you want to, you can set these for each parameter sensitivity separatley. So CVODES should let us tune things to higher accuracy.
Although, I have to say that I don't yet fully understand why such high accuracy sensitivites are needed. Do you have examples somewhere which show what goes wrong? I mean, I am getting very good inferences from Stan when using ODEs. Maybe things are not ultra-precise, but in my applications the accuracy is sufficient enough. At least from what I can say.
But to come back to CVODES: The implementation passes all tests which were written for CVODE; what else is needed to merge this? The increased accuracy story is separate to this and should be dealt with in another issue+pull request, no?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

No one expects ODEs to be so super-precised solved. If that matters for NuTS, ok then this is a different story. Of course, we have to define at what tolerances we want comparisons to be run.
I followed your suggestion of putting 1E-10 abs+rel tolerances in the test case I provided. The old CVODE+coupled system does fail here again while the CVODES implementation passes this test.

Hi!
I added a further performance test case, i.e. this time one which is possibly a minimal example. The ODE model consists of 2 states and 4 parameters only. Essentially, one state becomes activated and then becomes deactivated again. Both reactions are governed by a michaelis menten type rate . The ODE system is
ydot[0] = -1*(act*y[0]/(KmA+y[0]))+1*(deact*y[1]/(KmAp+y[1]));
ydot[1] =  1*(act*y[0]/(KmA+y[0]))-1*(deact*y[1]/(KmAp+y[1]));

Moreover, I increased absolute and relative tolerance to 1E-10. The new smaller test case does again fail with the old cvode+coupled system which manages to integrate 24 times the system within a minute time. The new CVODES system instead runs 100 integrations in 0.1s.
Michaelis-Menten ODEs are a primary application area for the ODE solver in Stan. At least for my application purposes.

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be.   My thinking is that until the error's higher than MCMC error,
it's not going to matter much.  If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

The problem is that the ODE errors can potentially aggregate coherently over multiple time
points and multiple systems (for example, multiple patients).
@wds15, here is what I think needs to be done before a pull request.

Study the effect of ODE error on final results.

1a) Take a few ODE models that span typical applications, including one exact model
(such as the one in test/unit/math/rev/arr/functor/integrate_ode_cvode_grad_rev_test.cpp).
I suggest an SIR model and a hierarchical PK/PD type model � the ones I just sent to
the dev list for R tests would be reasonable.
1b) Run with CVODE (or CVODES if you prefer) with very small rel and abs tolerances
(see if 1e-14 or even 1e-16 will run in a reasonable amount of time) and many samples
to get �exact� values of the parameter means, variances, and MCMC standard errors.  In
addition, take a few posterior samples and get the ODE states vs time, treating these as
�exact� values as well.
1c) Now scan through abs/rel tolerances, say jumping 2 orders of magnitude at each
step until you get to 1e-2.  For each tolerance record the parameter means, variances,
standard errors, and the states vs time for the above posterior samples.
Use the states vs time to quantify the actual error in the ODE solver for each setting.
Plot actual error vs abs/rel tolerance and the mean/variances/standard errors vs
abs/rel tolerance.
1d) We should hopefully see a cut off where the abs/rel tolerance is low enough that
there are no effects on the MCMC estimation.  We then set that at the benchmark
in our tests and tune the existing ODE solver defaults to achieve that benchmark.
Then we�ll be in a position to properly judge new samplers.

Add CVODES as a new solver OR replace CVODE with CVODES.  I�m fine with
either, but either copy the existing CVODE implementation or just drop in CVODES
for CVODE.  Don�t change any of the architecture yet.

Then we can talk about further changes.

On Mar 22, 2016, at 8:03 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be. My thinking is that until the error's higher than MCMC error,
it's not going to matter much. If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

�
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

I understand what (and why) you want to test.  So I think
we should start with our existing solvers.  It sounds from
Sebastian's experiments that the two existing solvers will fail
at 1e-10 tolerances whereas CVODES will succeed.  That'd be
a very convincing case for including it above and beyond the
speed (the problem is that we only care about speed conditioned
on getting a good enough result for our applications).

Bob

On Mar 22, 2016, at 5:17 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
The problem is that the ODE errors can potentially aggregate coherently over multiple time
points and multiple systems (for example, multiple patients).
@wds15, here is what I think needs to be done before a pull request.

Study the effect of ODE error on final results.

1a) Take a few ODE models that span typical applications, including one exact model
(such as the one in test/unit/math/rev/arr/functor/integrate_ode_cvode_grad_rev_test.cpp).
I suggest an SIR model and a hierarchical PK/PD type model � the ones I just sent to
the dev list for R tests would be reasonable.
1b) Run with CVODE (or CVODES if you prefer) with very small rel and abs tolerances
(see if 1e-14 or even 1e-16 will run in a reasonable amount of time) and many samples
to get �exact� values of the parameter means, variances, and MCMC standard errors. In
addition, take a few posterior samples and get the ODE states vs time, treating these as
�exact� values as well.
1c) Now scan through abs/rel tolerances, say jumping 2 orders of magnitude at each
step until you get to 1e-2. For each tolerance record the parameter means, variances,
standard errors, and the states vs time for the above posterior samples.
Use the states vs time to quantify the actual error in the ODE solver for each setting.
Plot actual error vs abs/rel tolerance and the mean/variances/standard errors vs
abs/rel tolerance.
1d) We should hopefully see a cut off where the abs/rel tolerance is low enough that
there are no effects on the MCMC estimation. We then set that at the benchmark
in our tests and tune the existing ODE solver defaults to achieve that benchmark.
Then we�ll be in a position to properly judge new samplers.

Add CVODES as a new solver OR replace CVODE with CVODES. I�m fine with
either, but either copy the existing CVODE implementation or just drop in CVODES
for CVODE. Don�t change any of the architecture yet.

Then we can talk about further changes.

On Mar 22, 2016, at 8:03 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be. My thinking is that until the error's higher than MCMC error,
it's not going to matter much. If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

�
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

Right.  I have no objections to putting CVODES in
once Sebastian explained that it used our autodiff
with callbacks, I just want to make sure we formalize
our testing thresholds now that we’re transitioning
from a solver to multiple solvers.
On Mar 22, 2016, at 9:56 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

I understand what (and why) you want to test. So I think
we should start with our existing solvers. It sounds from
Sebastian's experiments that the two existing solvers will fail
at 1e-10 tolerances whereas CVODES will succeed. That'd be
a very convincing case for including it above and beyond the
speed (the problem is that we only care about speed conditioned
on getting a good enough result for our applications).

Bob

On Mar 22, 2016, at 5:17 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
The problem is that the ODE errors can potentially aggregate coherently over multiple time
points and multiple systems (for example, multiple patients).
@wds15, here is what I think needs to be done before a pull request.

Study the effect of ODE error on final results.

1a) Take a few ODE models that span typical applications, including one exact model
(such as the one in test/unit/math/rev/arr/functor/integrate_ode_cvode_grad_rev_test.cpp).
I suggest an SIR model and a hierarchical PK/PD type model � the ones I just sent to
the dev list for R tests would be reasonable.
1b) Run with CVODE (or CVODES if you prefer) with very small rel and abs tolerances
(see if 1e-14 or even 1e-16 will run in a reasonable amount of time) and many samples
to get �exact� values of the parameter means, variances, and MCMC standard errors. In
addition, take a few posterior samples and get the ODE states vs time, treating these as
�exact� values as well.
1c) Now scan through abs/rel tolerances, say jumping 2 orders of magnitude at each
step until you get to 1e-2. For each tolerance record the parameter means, variances,
standard errors, and the states vs time for the above posterior samples.
Use the states vs time to quantify the actual error in the ODE solver for each setting.
Plot actual error vs abs/rel tolerance and the mean/variances/standard errors vs
abs/rel tolerance.
1d) We should hopefully see a cut off where the abs/rel tolerance is low enough that
there are no effects on the MCMC estimation. We then set that at the benchmark
in our tests and tune the existing ODE solver defaults to achieve that benchmark.
Then we�ll be in a position to properly judge new samplers.

Add CVODES as a new solver OR replace CVODE with CVODES. I�m fine with
either, but either copy the existing CVODE implementation or just drop in CVODES
for CVODE. Don�t change any of the architecture yet.

Then we can talk about further changes.

On Mar 22, 2016, at 8:03 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be. My thinking is that until the error's higher than MCMC error,
it's not going to matter much. If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

�
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Do these tests already exist for the first two solvers
(Runge-Kutta from Boost and CVODE from Sundials)?

Bob

On Mar 22, 2016, at 5:58 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Right. I have no objections to putting CVODES in
once Sebastian explained that it used our autodiff
with callbacks, I just want to make sure we formalize
our testing thresholds now that we’re transitioning
from a solver to multiple solvers.
On Mar 22, 2016, at 9:56 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

I understand what (and why) you want to test. So I think
we should start with our existing solvers. It sounds from
Sebastian's experiments that the two existing solvers will fail
at 1e-10 tolerances whereas CVODES will succeed. That'd be
a very convincing case for including it above and beyond the
speed (the problem is that we only care about speed conditioned
on getting a good enough result for our applications).

Bob

On Mar 22, 2016, at 5:17 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
The problem is that the ODE errors can potentially aggregate coherently over multiple time
points and multiple systems (for example, multiple patients).
@wds15, here is what I think needs to be done before a pull request.

Study the effect of ODE error on final results.

1a) Take a few ODE models that span typical applications, including one exact model
(such as the one in test/unit/math/rev/arr/functor/integrate_ode_cvode_grad_rev_test.cpp).
I suggest an SIR model and a hierarchical PK/PD type model � the ones I just sent to
the dev list for R tests would be reasonable.
1b) Run with CVODE (or CVODES if you prefer) with very small rel and abs tolerances
(see if 1e-14 or even 1e-16 will run in a reasonable amount of time) and many samples
to get �exact� values of the parameter means, variances, and MCMC standard errors. In
addition, take a few posterior samples and get the ODE states vs time, treating these as
�exact� values as well.
1c) Now scan through abs/rel tolerances, say jumping 2 orders of magnitude at each
step until you get to 1e-2. For each tolerance record the parameter means, variances,
standard errors, and the states vs time for the above posterior samples.
Use the states vs time to quantify the actual error in the ODE solver for each setting.
Plot actual error vs abs/rel tolerance and the mean/variances/standard errors vs
abs/rel tolerance.
1d) We should hopefully see a cut off where the abs/rel tolerance is low enough that
there are no effects on the MCMC estimation. We then set that at the benchmark
in our tests and tune the existing ODE solver defaults to achieve that benchmark.
Then we�ll be in a position to properly judge new samplers.

Add CVODES as a new solver OR replace CVODE with CVODES. I�m fine with
either, but either copy the existing CVODE implementation or just drop in CVODES
for CVODE. Don�t change any of the architecture yet.

Then we can talk about further changes.

On Mar 22, 2016, at 8:03 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be. My thinking is that until the error's higher than MCMC error,
it's not going to matter much. If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

�
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

Yes, although with somewhat arbitrary accuracy thresholds.
I want to motivate better thresholds before moving forwards.
On Mar 22, 2016, at 10:06 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

Do these tests already exist for the first two solvers
(Runge-Kutta from Boost and CVODE from Sundials)?

Bob

On Mar 22, 2016, at 5:58 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
Right. I have no objections to putting CVODES in
once Sebastian explained that it used our autodiff
with callbacks, I just want to make sure we formalize
our testing thresholds now that we’re transitioning
from a solver to multiple solvers.
On Mar 22, 2016, at 9:56 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

I understand what (and why) you want to test. So I think
we should start with our existing solvers. It sounds from
Sebastian's experiments that the two existing solvers will fail
at 1e-10 tolerances whereas CVODES will succeed. That'd be
a very convincing case for including it above and beyond the
speed (the problem is that we only care about speed conditioned
on getting a good enough result for our applications).

Bob

On Mar 22, 2016, at 5:17 PM, Michael Betancourt<EMAIL_ADDRESS>wrote:
The problem is that the ODE errors can potentially aggregate coherently over multiple time
points and multiple systems (for example, multiple patients).
@wds15, here is what I think needs to be done before a pull request.

Study the effect of ODE error on final results.

1a) Take a few ODE models that span typical applications, including one exact model
(such as the one in test/unit/math/rev/arr/functor/integrate_ode_cvode_grad_rev_test.cpp).
I suggest an SIR model and a hierarchical PK/PD type model � the ones I just sent to
the dev list for R tests would be reasonable.
1b) Run with CVODE (or CVODES if you prefer) with very small rel and abs tolerances
(see if 1e-14 or even 1e-16 will run in a reasonable amount of time) and many samples
to get �exact� values of the parameter means, variances, and MCMC standard errors. In
addition, take a few posterior samples and get the ODE states vs time, treating these as
�exact� values as well.
1c) Now scan through abs/rel tolerances, say jumping 2 orders of magnitude at each
step until you get to 1e-2. For each tolerance record the parameter means, variances,
standard errors, and the states vs time for the above posterior samples.
Use the states vs time to quantify the actual error in the ODE solver for each setting.
Plot actual error vs abs/rel tolerance and the mean/variances/standard errors vs
abs/rel tolerance.
1d) We should hopefully see a cut off where the abs/rel tolerance is low enough that
there are no effects on the MCMC estimation. We then set that at the benchmark
in our tests and tune the existing ODE solver defaults to achieve that benchmark.
Then we�ll be in a position to properly judge new samplers.

Add CVODES as a new solver OR replace CVODE with CVODES. I�m fine with
either, but either copy the existing CVODE implementation or just drop in CVODES
for CVODE. Don�t change any of the architecture yet.

Then we can talk about further changes.

On Mar 22, 2016, at 8:03 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

On Mar 21, 2016, at 7:48 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
...
I am here referring to the former and how accurate we need the numerical solutions to be before
the numerical errors significantly biases our MCMC estimators. My intuition is that 1e-5 is too large,

My guess is that while 1e-5 may be a problem, I doubt 1e-7 is going
to be. My thinking is that until the error's higher than MCMC error,
it's not going to matter much. If our outcomes are order 1e0 and our
posterior std devs are order 1e-2, then error of 1e-7 is barely worth
worrying about --- it's on the order of MCMC error (and yes, I understand
that the error here is biased, not just noisy like MCMC error).
I may be way off base, of course!

Bob

�
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

I fully agree that a good understanding of ODE estimation error and MCMC error is very valuable. However, I have to say that I doubt that we can ever cover the space of models/parameters reasonably well as there are too many unkowns (and unknown unkowns). That said, I can use a program I have written a while ago to look a bit into this. This problem is a hierarchical PK/PD problem where I simulate from some true values and then use a Stan program which I can switch between using an analytic solution OR the ode integrator. I guess this would be a good base to do such a study - and I am definetly myself very interested in such results as I am interested in the question of how low I can set the precision and still be safe.
For the stiff ODE performance tests I am not so sure if we need to tune this to ultra-high precision. I mean these are tough problems and I am happy to live with a somewhat biased solution rather than none. I know that I am coming here a bit from the other side yes, and I do agree that understanding bias also in these settings is valuable, I just doubt it will be practical to insist on ulta-high precision (although I have set  CVODES to 1E-10 which should be a "true" 1E-8).
I guess you speak of the *_grad_test.cpp tests which do test at precisions of 1E-8 and 1E-7. To me that sounds enough, but for the moment we could just bump that to a higher precision (1E-10?) and possibly later revise this setting after all those tests? I mean, the benefit of CVODES can be very large for our users.

You are completely speculating here.  If we’re going to be comparing
solvers then we need to be more careful, and the studies I laid out
are straightforward and at least partially quantify the effect of the
solver tolerances.
On Mar 23, 2016, at 10:41 AM, wds15<EMAIL_ADDRESS>wrote:

I fully agree that a good understanding of ODE estimation error and MCMC error is very valuable. However, I have to say that I doubt that we can ever cover the space of models/parameters reasonably well as there are too many unkowns (and unknown unkowns). That said, I can use a program I have written a while ago to look a bit into this. This problem is a hierarchical PK/PD problem where I simulate from some true values and then use a Stan program which I can switch between using an analytic solution OR the ode integrator. I guess this would be a good base to do such a study - and I am definetly myself very interested in such results as I am interested in the question of how low I can set the precision and still be safe.
For the stiff ODE performance tests I am not so sure if we need to tune this to ultra-high precision. I mean these are tough problems and I am happy to live with a somewhat biased solution rather than none. I know that I am coming here a bit from the other side yes, and I do agree that understanding bias also in these settings is valuable, I just doubt it will be practical to insist on ulta-high precision (although I have set CVODES to 1E-10 which should be a "true" 1E-8).
I guess you speak of the *_grad_test.cpp tests which do test at precisions of 1E-8 and 1E-7. To me that sounds enough, but for the moment we could just bump that to a higher precision (1E-10?) and possibly later revise this setting after all those tests? I mean, the benefit of CVODES can be very large for our users.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

The fact that we can't cover every contingency with a suite
of benchmarks shouldn't stop us from building a couple just to see
how things work.   As Sebastian says, we want to know this in
order to provide advice to users anyway.
I believe all that Michael's asking for here is to show that
CVODES works at least as well as CVODE in terms of precision
and that it's faster, which would motivate replacing CVODE.
Even if we weren't comparing CVODES, we'd want these tests
anyway.
Given that we will have user-settable precision, the decision
on whether to sacrifice some bias for some speed will be up
to users anyway.

Bob

Yes, as I said, I can run those tests on a model I have prepared. All simulated stuff and direct comparison with an analytic solution, I guess this is the best comparison we can do. Agree?
Given that we consider these tolerances as very important, I could enable the possibility to set an absolute tolerance PER state within CVODES (which will appropiatley propagate to the sensitivities). Does that make sense? So we would have two functions, one taking a vector of abs_tols and one taking just a real which gets applied to all states. Then the user can decide for which state he is willing to pay a large performance price or not. This is recommended practice from the CVODES user manual.
Wrt. to precisions: There are tests in Stan which are set to 1E-7 and 1E-8 right now and CVODES does pass these, just as CVODE does. To expedite this pull request I was suggesting to upping that to 1E-10 for now... higher precisions will anyway be a problem for about any solver as the double machine precision is around 1E-14.

I was very clear in my original email what we need to first see.
An ensemble of models (I can provide explicit models if this is
a problem) and scan of tolerances to see the ultimate effect
on inferences across those models.
On Mar 23, 2016, at 4:20 PM, wds15<EMAIL_ADDRESS>wrote:

Yes, as I said, I can run those tests on a model I have prepared. All simulated stuff and direct comparison with an analytic solution, I guess this is the best comparison we can do. Agree?
Given that we consider these tolerances as very important, I could enable the possibility to set an absolute tolerance PER state within CVODES (which will appropiatley propagate to the sensitivities). Does that make sense? So we would have two functions, one taking a vector of abs_tols and one taking just a real which gets applied to all states. Then the user can decide for which state he is willing to pay a large performance price or not. This is recommended practice from the CVODES user manual.
Wrt. to precisions: There are tests in Stan which are set to 1E-7 and 1E-8 right now and CVODES does pass these, just as CVODE does. To expedite this pull request I was suggesting to upping that to 1E-10 for now... higher precisions will anyway be a problem for about any solver as the double machine precision is around 1E-14.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Hi!
Not sure where to put this, but I don't want to spam the dev list (maybe I should?) with this. So here are the results for a hierarchical PK/PD model. To be specific, I simulated 50 patients of a 2-cmt model oral dosing situation for typical parameter values I use to see. Two doses (t=0 and t=24) are given and I compare against an analytic solution which I placed on the very left of the plots with abs_tol=1E-16 for machine precision. Now, I had to use the CVODES implementation as the CVODE+coupled did freeze Stan for 3 days while CVODES returned the results in few hours, depending on the abs+rel tolerance set. I used a 1E-9, 1E-6 and a 1E-3 abs+rel tolerance. Have a look yourself, but I can't find any threshold. I used 4 chains and per chain I did 500 warmups and 500 iterations. True values are
   theta_true <-  c(0.326634259978281, 0, 2.30258509299405, 1.6094379124341, 3.68887945411394)
  omega_true <-  c(0.3, 0.4)
  sigma_y_true <- 0.2

metrics.pdf

So all tests are brought in line with at least 1E-6 abs+rel tolerance and I added a
integrate_ode_cvodes
function which takes a solver argument. Of course, we can quickly adapt to whatever naming convention we end up with (probable the _stiff naming).
@bob-carpenter , @betanalpha a code review from one of you would be great. At the moment a high-level feedback would be very useful for me to shape this thing up for a pull request.
There are still cpplint errors... will attack them soon.

I can do a basic code review tomorrow.  Michael will be
better at picking up math issues, but I can do the basics.

On Apr 5, 2016, at 6:50 PM, wds15<EMAIL_ADDRESS>wrote:
So all tests are brought in line with at least 1E-6 abs+rel tolerance and I added a
integrate_ode_cvodes
function which takes a solver argument. Of course, we can quickly adapt to whatever naming convention we end up with (probable the _stiff naming).
@bob-carpenter , @betanalpha a code review from one of you would be great. At the moment a high-level feedback would be very useful for me to shape this thing up for a pull request.
There are still cpplint errors... will attack them soon.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub


How to pass array as parameter on deploy using goloop CLI ?

Hello,
I'd like to know if that's possible to pass an array as a parameter of goloop rpc sendtx deploy.
This issue is slightly related to https://github.com/icon-project/goloop/issues/66 .
Right now the documentation only mentions a --param flag, but doesn't accept a --raw flag like goloop rpc call.
Is there an existing format for passing an array as a parameter using --param ?

Repro:
package com.iconloop.score.example;

import java.math.BigInteger;

import score.Context;
import score.ArrayDB;
import score.annotation.External;

public class HelloWorld {

    private final ArrayDB<BigInteger> array = Context.newArrayDB("array", BigInteger.class);

    public HelloWorld(BigInteger[] _array) {
        for (var item : _array) {
            this.array.add(item);
        }
    }

    @External(readonly = true)
    public BigInteger get_item (int index) {
        return this.array.get(index);
    }
}

Goloop CLIP command :
goloop rpc sendtx deploy helloworld-optimized.jar \
    --content_type application/java \
    --key_store ${key_store} \
    --key_password=${key_password} \
    --nid ${nid} \
    --step_limit ${step_limit} \
    --uri ${uri} \
    --param _array=???

Yeah... currently the CLI interface doesn't support complex types like array as an input parameter.
You could use raw or raw2 sub-command in sendtx to send transaction with a json file, but if you want to use this command in deployment scenario, you need to convert the jar file into large hexastring and save it into the json file, this is somewhat cumbersome.
The CLI interface is for quick query or invoking transactions on-the-fly, not for working with testing framework or official deployment. Thus I'd like to recommend to use ICON SDK either Java or Python for your testing or official deployment.  Please refer to deploy script in Multi-Token Standard repository.

Thanks ! I'll move on SDKs then.


Can Crown support prune blockchain?

Can Crown support prune blockchain same as BTC, LTC, DGB, ...?

It will with the new Bitcoin updates which are incoming.
Issue can be closed @walkjivefly


Abra will realign duplicates?

I just had a question regarding release 0.92
Will Abra realign duplicates or ignore these reads? Thank you for the help

Thank you very much for the information 👍

"By "where appropriate", that means when the duplicate reads map more closely to the new reference than to the old reference, correct?"
Yes, that's correct.  After assembly, the duplicate reads are realigned the same way as the non-duplicates.
Will be very interested in seeing your results,  thanks!

Just to circle back on this, we ran our pipeline with and without MarkDuplicates step removed, and noticed and slight change in alt allele frequency, although because we are working with UMIs there are some complicating factors that may have contributed to this discrepancy. For now we'll be leaving in the MarkDuplicates step.


Add Dhanshree

@pz-max here we go!

Awesome!
Can you add youself as well to the about-us.html page?
https://github.com/open-energy-transition/oet-website/blob/baaa47fe32ee30ea1b8fe0a975c16ae901605ddb/about-us.html#L332-L344
Please use the "Live-Preview" add-on to locally test the about-us.html page on your side. (once you have the add-on, right click on the html file and then click on live-preview.)

Hey @pz-max, I missed that, my bad :grimacing: hope this looks good? :D

@DhanshreeA I like it


Firebase APNS device token not set before retrieving FCM Token for Sender ID - XXX Flutter iOS

Hello
Push notifications were working fine before but now all of sudden getting " [Firebase APNS device token not set before retrieving FCM Token for Sender ID - Flutter iOS] . I am using latest version and 11.2.5 for my other project .
Is this issue related to firebase_messaging . ?
Please help .

@rak54
If you try on any other iOS device, do you get same error ?
Also, there's a discussion thread on this issue, that you need to follow-up in and check underlying comments to see if they help.
Closing from here.

Yes I am not getting messages on other devices too
On Thu, Sep 22, 2022, 3:20 PM darshankawar @.***> wrote:

@rak54 https://github.com/rak54
If you try on any other iOS device, do you get same error ?
Also, there's a discussion
https://github.com/firebase/flutterfire/discussions/5705 thread on this
issue, that you need to follow-up in and check underlying comments to see
if they help.
Closing from here.
—
Reply to this email directly, view it on GitHub
https://github.com/firebase/flutterfire/issues/9589#issuecomment-1254823095,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYBHVANTLZ2TNSQSS4BV4OTV7QXE7ANCNFSM6AAAAAAQSX3HMA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes I have seen that discussion and everything thing is fine by my side
still won't work
On Thu, Sep 22, 2022, 3:31 PM Rashid Hussain @.***> wrote:

Yes I am not getting messages on other devices too
On Thu, Sep 22, 2022, 3:20 PM darshankawar @.***>
wrote:

@rak54 https://github.com/rak54
If you try on any other iOS device, do you get same error ?
Also, there's a discussion
https://github.com/firebase/flutterfire/discussions/5705 thread on
this issue, that you need to follow-up in and check underlying comments to
see if they help.
Closing from here.
—
Reply to this email directly, view it on GitHub
https://github.com/firebase/flutterfire/issues/9589#issuecomment-1254823095,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYBHVANTLZ2TNSQSS4BV4OTV7QXE7ANCNFSM6AAAAAAQSX3HMA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add ability to display global settings with 'show' command

Allow the user to use wa show settings to display global configuration settings.

Implemented in https://github.com/ARM-software/workload-automation/pull/688


drivers: display: add support for RM68200 display to RT595

Add support for the RM68200 display with the RT595 EVK. This PR includes the following new drivers:

LCDIF display driver for RT595 LCDIF IP
MIPI DSI driver for RT595 MIPI IP block

In addition, the following drivers have been updated:

RM68200 driver now manages power pin directly, so that regulator API is not required to manage panel power
FlexSPI MEMC driver now permits reserving AHB RX buffer space for specific AHB masters. This can greatly improve performance
support for querying LCDIF clock rates has been added to LPC syscon clock control driver

This PR was tested with the LVGL widgets sample, as well as samples/drivers/display, on the RT595 and RT1170 EVK using the RK055HDMIPI4M display
Signed-off-by: Daniel DeGrasse<EMAIL_ADDRESS>

Please update the west file.


Auto-confirm commit message and push via CLI argument

First of all, very cool project! Question for you:
Is there an argument (or arguments) that can be passed (e.g. oco --confirm yes --push yes) to enable the oco command to complete a commit and push without user input? Would like to use this as part of a custom CI/CD script but need to automate these steps first.
Thanks!
https://github.com/di-sukharev/opencommit/blob/916ddf02d1fcbf6082362e153262e177e39b743b/src/commands/commit.ts#L66C5-L66C5

I've added this is a PR #227


[Patch 1.1.4] ResponseBodyTests.ResponseBody_SecondWriteAsyncWithCanceledCancellationToken_CancelsAndAborts flakiness

Could we skip \ fix this?
Assert.Throws() Failure
Expected: typeof(System.Net.Http.HttpRequestException)
Actual:   typeof(System.Threading.Tasks.TaskCanceledException): A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Net.Http.Server.ResponseBodyTests.<SendRequestAsync>d__23.MoveNext() in C:\b\w\d6337ac2abf63a4b\.repositories\WebListener\test\Microsoft.Net.Http.Server.FunctionalTests\ResponseBodyTests.cs:line 611
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

cc @Eilon \ @Tratcher

I will use the current dev branch as a reference for disabling flaky tests. I will be disabling tests in both 1.1.4 and 1.0.6.


How to coerce Rust memory into Javascript generically

Hello,
I created a trait that would allow me to coerce slices into JS datatypes:
pub trait FromJsSys {
    fn from_js_sys(memory: &JsValue, data: Self) -> Uint8ClampedArray;
}

macro_rules! from_js_sys {
    ($type:ty, $id:ident) => {
        impl FromJsSys for $type {
            fn from_js_sys(memory: &JsValue, data: $type) -> Uint8ClampedArray {
                let data_size = data.len();
                let data_pointer = data.as_ptr() as u32;
                let data_normalization = size_of_val(&data[0]) as u32;
                let data_location = data_pointer / data_normalization;
                $id::new(&memory)
                    .slice(data_location, data_location + data_size as u32)
            }
        }
    };
}

from_js_sys!(&[f32], Float32Array);

//...

let vertices: [f32; 9] = [-0.7, -0.7, 0.0, 0.7, -0.7, 0.0, 0.0, 0.7, 0.0];
FromJsSys::from_js_sys(&vertices[..]);

However, when I look at the console I have the error: wasm-bindgen: imported JS function that was not marked as catch threw an error: TypeError: "attempting to access detached ArrayBuffer"
Is this due to the memory being resized?

It seems as though that Context impl is using an intrinsic wasm-bindgen function to call the JS, am I right? Would I have to create a javascript function that takes two arrays and returns if they are equal using ===?
Also, if one is not equal, do we assume all of them are not equal and we'd have to recreate every single global buffer in our application?

You should be able to === inside of Rust using PartialEq for JsValue, and yeah if equality doesn't hold up then anything using the previous ArrayBuffer needs to be recreated

Thank you Alex, that makes a lot of sense!

Hm I'm not sure I quite understand? But in any case all typed arrays in JS are backed by an ArrayBuffer and so is WebAssembly.Memory, but the array buffer behind WebAssembly.Memory can change over time and when it does you need to recreate any typed arrays that were views into the previous one.
The ArrayBuffer itself is gc'd in JS and typically the same instance is shared amongst things, and AFAIK you have to explicitly clone them and no implicit clones happen.

Ah, I was misunderstanding. So I'll need to create a new handle to my Memory JSValue when this happens, and then recreate all of the views that I had before. The only other thing that I don't understand is how would I check if the memory sized? Would I create a new memory and test it against the old one:
let test = wasm_bindgen::memory()
        .dyn_into::<WebAssembly::Memory>()
        .unwrap();

if test == old_memory {
    //.. redo memory views
}

To test if it's resized you'll want to access the buffer property to get the underlying ArrayBuffer and then equate that with the previous ArrayBuffer which you'll want to store from before


Docs/Samples - please replace all uses of node with Node.js for clarity.

This storage sample uses the word node to indicate the functionality is only available on Node.js.
Please change all occurences of node to Node.js for clarity. If this is about functionality that specifically only run in Node.js or browser, please use the same exact text as the NPM readme:
"ONLY AVAILABLE IN NODE.JS RUNTIME" or "ONLY AVAILABLE IN BROWSERS".
The samples need to be consistent with the ref docs and the readme has stated this is the guideline text.

I see the bot as added storage and client but this comment is about all samples across the repo.