Add derivatives for mvn

[spinkney]

Summary

This PR adds derivatives for the multi_normal_lpdf.

Tests

Added the derivative tests in test/unit/math/rev/prob/multi_normal_test.cpp

Side Effects

No

Release notes

Added hand-calculated derivatives for the multivariate normal lpdf.

Checklist

• Copyright holder: Sean Pinkney

  The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
  - Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
  - Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

• the basic tests are passing

  • unit tests pass (to run, use: ./runTests.py test/unit)
  • header checks pass, (make test-headers)
  • dependencies checks pass, (make test-math-dependencies)
  • docs build, (make doxygen)
  • code passes the built in C++ standards checks (make cpplint)

• the code is written in idiomatic C++ and changes are documented in the doxygen

• the new changes are tested

[spinkney]

This test now passes
The derivative tests fail with

./stan/math/prim/prob/multi_normal_lpdf.hpp:237:11: note: in instantiation of function template specialization 'Eigen::Matrix<double, -1, 1>::operator=<Eigen::Matrix<stan::math::var_value<double>, -1, 1>>' requested here
     half = mdivide_left_ldlt(ldlt_Sigma, y_val_minus_mu_val);

The offending code is at

math/stan/math/prim/prob/multi_normal_lpdf.hpp

Line 239 in 208658a

half = mdivide_left_ldlt(ldlt_Sigma, y_val_minus_mu_val);

. I believe the ldlt_factor needs to be a double but it's passing a const stan::math::var_value<double>. This is beyond my current cpp skills.

[spinkney]

@bgoodri this doesn't benchmark any faster than the current autodiff code. Does it make sense to add this for stability or should we just keep the current autodiffed code?

[bgoodri]

@bgoodri this doesn't benchmark any faster than the current autodiff code. Does it make sense to add this for stability or should we just keep the current autodiffed code?

I would say that if it is no slower, then having the analytical derivatives is worth it because it consumes less RAM.

[spinkney]

@SteveBronder this should be good for a review once the CI finishes

[syclik]

@spinkney, just letting you know there are merge conflicts; @SteveBronder approved the PR!

[spinkney]

@syclik @SteveBronder fixed the merge conflict and updated to the develop branch. If this passes then it should be good to go!

[spinkney]

@serban-nicusor-toptal does CI need to be restarted? I've never seen this error before.

[stan-buildbot]

---

Name	Old Result	New Result	Ratio	Performance change( 1 - new / old )
arma/arma.stan	0.19	0.18	1.05	4.95% faster
low_dim_corr_gauss/low_dim_corr_gauss.stan	0.01	0.01	1.16	13.84% faster
gp_regr/gen_gp_data.stan	0.02	0.02	1.09	8.1% faster
gp_regr/gp_regr.stan	0.11	0.1	1.06	5.56% faster
sir/sir.stan	76.7	74.34	1.03	3.07% faster
irt_2pl/irt_2pl.stan	3.87	3.9	0.99	-0.98% slower
eight_schools/eight_schools.stan	0.05	0.05	0.95	-5.44% slower
pkpd/sim_one_comp_mm_elim_abs.stan	0.24	0.25	0.96	-4.32% slower
pkpd/one_comp_mm_elim_abs.stan	17.94	18.19	0.99	-1.38% slower
garch/garch.stan	0.45	0.46	0.97	-3.37% slower
low_dim_gauss_mix/low_dim_gauss_mix.stan	2.78	2.81	0.99	-0.99% slower
arK/arK.stan	1.77	1.65	1.08	7.08% faster
gp_pois_regr/gp_pois_regr.stan	2.5	2.57	0.97	-2.89% slower
low_dim_gauss_mix_collapse/low_dim_gauss_mix_collapse.stan	9.07	9.2	0.99	-1.43% slower
performance.compilation	173.0	172.88	1.0	0.07% faster
Mean result: 1.0178292792328905

---

Jenkins Console Log
Blue Ocean
Commit hash: f70fb84db501edcbf822691c02664c43b76287b2

---

Machine information

No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal

CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 80
On-line CPU(s) list: 0-79
Thread(s) per core: 2
Core(s) per socket: 20
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Stepping: 4
CPU MHz: 2400.000
CPU max MHz: 3700.0000
CPU min MHz: 1000.0000
BogoMIPS: 4800.00
Virtualization: VT-x
L1d cache: 1.3 MiB
L1i cache: 1.3 MiB
L2 cache: 40 MiB
L3 cache: 55 MiB
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Retbleed: Mitigation; IBRS
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; IBRS, IBPB conditional, STIBP conditional, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke md_clear flush_l1d arch_capabilities

G++:
g++ (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Clang:
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[serban-nicusor-toptal]

Jenkins shenanigans, everything looks fine now!

[WardBrian]

Our CI has a minor race condition where the exact following sequence of events can cause trouble

1. A math/stan pipeline starts
2. A merge is made to stanc3 which adds a new feature with new test models
3. The math/stan pipeline reaches the point where it tries to build said test models
4. The stanc3 pipeline finishes building binaries and uploading them

Step (3) will fail because it is still using the stanc3 binaries from before the merge in (2)

There isn't a good way (that I know of) to avoid this, so just giving the pipeline a kick to restart when this does happen seems like the best thing to do