text:
Implementing QG Leith

What changes does this PR introduce?
Implementation of QG Leith subgrid model as described in Bachman et al. (2017) and Pearson et al. (2017).
Other information:
This branch is not ready to be merged. It is intended to provide a space for collaboration as we work on the code.
The initial code dump has been placed within the verification folder as a subtle reminder that we will need a test for this new functionality before it can be merged.
To do
This list constitutes an initial pass - there is more to do than listed here. Some additional issues are described in 'QG_LEITH_README'

[x] remove extraneous files
[x] remove CSV headers
[x] move subroutines to their correct homes within the source code
[x] Remove the dynamic computation of the Leith coefficient? Bachman et al. (2017) shows that it isn't particularly useful
[x] fix the boundary condition issue in calc_germanoK.F lines 328-335
[x] include a verification experiment that tests the new code
[x] new subroutine MOM_CALC_QG_STRETCHING is only called from mom_fluxform.F not mom_vecinv.F

I've invited @dfer22 and @septicscuzzy to be collaborators on my fork, so that they can push directly to this branch.

These two commits implement a QG version of Leith. They also have the limiter from eqn. (56) of Bachman et al. (2017) that should gracefully transition to 2D Leith as N^2 -> 0.
The code compiles, and turning it on by setting useLeithQG=.TRUE. and viscC2LeithQG = 1. in data for the verification experiment MLAdjust causes testreport to fail - so it is changing something about the solution. The biggest changes are for u and v, which bodes well, since that's what should change when viscosity changes.
default 10  ----T-----  ----S-----  ----U-----  ----V-----  --PTR 01--  --PTR 02--  --PTR 03--  --PTR 04--  --PTR 05--
G D M    c        m  s        m  s        m  s        m  s        m  s        m  s        m  s        m  s        m  s
e p a R  g  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .  m  m  e  .
n n k u  2  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d  i  a  a  d
2 d e n  d  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .  n  x  n  .

Y Y Y Y> 3<16 16 16  8 16 16 16 11  3  3  6  5  4  4  4  4  .  .  .  .  .  .  .  . FAIL  MLAdjust

The next step is to provide the option to use the LeithQG coefficient to do some mixing in the GMRedi package.

I ran a couple of toy simulations overnight and the output looks reasonable. The gif below is from a reentrant channel that was initialised with a tube of buoyant fluid at the surface. The instability grows and the viscosity increases as expected. Most of the domain was initially unstratified, so it seems as though this is able to cope with unstratified fluids.

The next phase of testing is to put it in some more complex models. I'll try it in a channel with complex forcings, a mixed layer, and sea ice. @septicscuzzy has committed to running one of the simulations from their paper with this code, so that we can compare the outputs.

Ed, can I try it in my channel, the one I used to test the normal 2D Leith? It would tick a lot of the things you mention above.

That would be sensational!

Just to be sure I'm doing the right thing:
I got your code this way:
git clone git@github.com:edoddridge/MITgcm.git
git checkout QG-Leith
and compiled.
Then, in the run, I set:
viscC2LeithQG=1
useLeithQG=1
all other Leith parameters to zero.
My reading of the code is that the divergent term is automatically included in QG Leith.
All good?

Yep, those commands will work and the divergence term is included. useLeithQG is a Boolean, and I'm not sure how robust casting fro integers to logicals is across compilers - might be better to use .TRUE.?
If you want to use the LeithQG coefficient in GM, you'll need to modify MOM_COMMON_OPTIONS.h and define ALLOW_GM_LEITH_QG.

I've added two new variants to the MLAdjust verification experiment - one uses LeithQG with GMRedi, the other without.

I tried testreport with gfortran and -devel and I got a Floating-point exception in mom_visc_qgleith_limiter
in both experiments (AhLeithQG and AhLeithQG_GM).

Thanks @jm-c, I'll look into that.
@septicscuzzy @dfer22 - how did your simulations turn out?
When used with GM, the current implementation doesn't allow for reproducible restarts. Since the viscosity is stored and used in GM on the following timestep, the first step after a restart will use different values. This can be fixed either by storing the viscosity in the pickup files, or calculating it before GM is called. It would be good to keep it out of the pickups, so I'll try calculating earlier in each timestep.

Not good, in comparison to my old experiments.  The KE spectra have ski
jumps.
However, I ran with useFullLeith = True on these, while it was False on the
old simulations.  I'll try switching to false and see if that changes
anything.
On Mon, Jun 4, 2018 at 8:47 AM, Ed Doddridge notifications@github.com
wrote:

Thanks @jm-c https://github.com/jm-c, I'll look into that.
@septicscuzzy https://github.com/septicscuzzy @dfer22
https://github.com/dfer22 - how did your simulations turn out?
When used with GM, the current implementation doesn't allow for
reproducible restarts. Since the viscosity is stored and used in GM on the
following timestep, the first step after a restart will use different
values. This can be fixed either by storing the viscosity in the pickup
files, or calculating it before GM is called. It would be good to keep it
out of the pickups, so I'll try calculating earlier in each timestep.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-394381145, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATrzIjWJAfPTQ_9PSv0paaT4hiNJEhJ9ks5t5UhlgaJpZM4Txn35
.

Ah, that's not ideal. That'd be great, thanks.

Well, if there was ever any question about whether UseFullLeith matters,
here is the answer:
I think these are close enough to the spectra from my original paper to be
satisfactory, given the numerous small changes that have been made (i.e.
limiters, fixing vorticity on the boundary, etc.).  I would definitely add
a warning to not use Full Leith with QG Leith, though.
On Mon, Jun 4, 2018 at 9:35 AM, Ed Doddridge notifications@github.com
wrote:

Ah, that's not ideal. That'd be great, thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-394399152, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATrzIlFgG4VY8cXN6vQAaavIwElKn26Yks5t5VPEgaJpZM4Txn35
.

I haven't seen them - did you mean to attach them to your comments?

I was referring to the spectra in the attachment on my June 5 email.  You
asked for "nice versions", but what does that mean?
On Thu, Jun 7, 2018 at 8:12 AM, Ed Doddridge notifications@github.com
wrote:

I haven't seen them - did you mean to attach them to your comments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-395434755, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATrzIqNM2YL8iLeST4W8utojAjfSBs0yks5t6TS0gaJpZM4Txn35
.

I'm pretty sure that attachments are ignored by GitHub when commenting via email - certainly nothing showed up here on the thread.

Apart from updating tag-index I think this is done. I'll leave that until it's been reviewed to avoid potential conflicts.

the floating point exception that @jm-c pointed out before has been fixed: testreport passes with the -devel option
the new functionality has been documented, including the runtime and compile time options, as well as a recommended value for the non-dimensional viscosity parameter
both locations in which the QGLeith viscosity is calculated (pkg/gmredi and pkg/mom_common) can output the array through pkg/diagnostics (and the values are extremely similar)
the GM functionality is now controlled by both compile time and runtime parameters, so it can be switched on and off at will

Good news: I checked that the MLAdjust examples pass test 2+2 ; also checked that results
don't change when I #define DYNAMICS_GUGV_EXCH_CHECK in dynamics.F, tested on CS-grid
with dry corners.
Regarding code changes:

currently, serious problems with Adjoint (I only tried TAF, none of verif exp can
even compile); We need a specific CPP option to protect this code (and 2 new calls
in mom_fluxform.F and mom_vecinv.F) from being always seen by TAF.
option ALLOW_GM_LEITH_QG  is set in 2 places and it's confusing. Since it's only
used in pkg/gmredi it should stay there and should be removed from MOM_COMMON_OPTIONS.h
what happens if I try: viscC2LeithQG=1 and useLeithQG=F ?
seems that results are different from full QG-Leith (=1,=T) but also different
from no QG-Leith at all (=0,=F).
Seems that in some part of the code it tests for viscC2LeithQG > 0 and in other places
it tests for useLeithQG, but would be better to to clarify this.
few "#include "MOM_VISC.h" have been added in pkg/gmredi but I am not convinced
that all are necessary. Also the 3 added *.F files could have shorter name, currently
mom_visc_qgleith_calc_stretching.F is the longest of any pkg, and all in lower-case
(except suffix .F) is preferable.

On Thu, Jul 12, 2018 at 02:16:09PM -0700, Ed Doddridge wrote:

Apart from updating tag-index I think this is done. I'll leave that until it's been reviewed to avoid potential conflicts.

the floating point exception that @jm-c pointed out before has been fixed: testreport passes with the -devel option
the new functionality has been documented, including the runtime and compile time options, as well as a recommended value for the non-dimensional viscosity parameter
both locations in which the QGLeith viscosity is calculated (pkg/gmredi and pkg/mom_common) can output the array through pkg/diagnostics (and the values are extremely similar)
the GM functionality is now controlled by both compile time and runtime parameters, so it can be switched on and off at will

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-404653335

Thanks @jm-c.
I've implemented all of your suggestions.

I haven't tested the adjoint, but I think I've managed to protect the new code with the ALLOW_LEITH_QG and ALLOW_GM_LEITH_QG CPP flags.

ALLOW_GM_LEITH_QG was only meant to be in GMREDI_OPTIONS.h, the copy in MOM_OPTIONS.h was an unintentional remnant. Thanks for catching it.

I removed the runtime logical parameter useLeithQG - there's now an internal equivalent that is set depending on the value of viscC2LeithQG .

Superfluous includes have been flushed.
4.1) File and subroutine names have been shortened.

@jrscott - I've documented these parameters in chapter 2, but they should also be added to the full list of parameters and cpp flags in the future.

yes, suggest we check it PR#123 (soon!) and then add the additional changes to the doc.
Also, can we make this more specific:
LeithQG viscosity is designed to work best in simulations that resolve some mesoscale features. In simulations that are too coarse to permit eddies or fine enough to resolve submesoscale features, it should fail gracefully.
sounds like this might be an option for eddy-permitting res runs that might still also use GM?  (i.e. mesoscale, "fail gracefully" are too vague). Be more specific in recommendation on when this might be a good option.

I run testreport but tutorial_cfc_offline failed to compile (gmredi_calc_qgleith.F). I also have one
adjoint experiment that fail to compile (tutorial_dic_adjoffline) but this could be for the same reason.

It's getting better, and the AD experiments are now running (except
tutorial_dic_adjoffline, cf previous comment) but some AD results have
changed a bit:
< Y Y Y Y 16>12<16 pass  1D_ocean_ice_column  (e=0, w=3)
< Y Y Y Y 16>12<16 pass  bottom_ctrl_5x5  (e=0, w=7)
< Y Y Y Y 16>13<16 pass  global_ocean.90x40x15  (e=0, w=15)
< Y Y Y Y 16>13<16 pass  halfpipe_streamice  (e=0, w=10)
< Y Y Y Y 16>13<16 pass  lab_sea.noseaicedyn
< Y Y N N .. .. .. N/O   tutorial_dic_adjoffline  (e=0, w=1)
< Y Y Y Y 14>13< 5 pass  tutorial_global_oce_biogeo  (e=0, w=6)
compared to previously:

Y Y Y Y 16>16<16 pass  1D_ocean_ice_column  (e=0, w=3)
Y Y Y Y 16>16<16 pass  bottom_ctrl_5x5  (e=0, w=7)
Y Y Y Y 16>16<16 pass  global_ocean.90x40x15  (e=0, w=15)

Y Y Y Y 16>16<16 pass  halfpipe_streamice  (e=0, w=10)

Y Y Y Y 16>16<16 pass  lab_sea.noseaicedyn

Y Y Y Y 16>16< 8 pass  tutorial_dic_adjoffline  (e=0, w=1)
Y Y Y Y 16>16<15 pass  tutorial_global_oce_biogeo  (e=0, w=6)
will need to investigate why it's like this.

Otherwise, I took a closer look to the code and have few comments:
Regarding coding:

the new subroutines: all the arguments should be documented inside,
and it does not hurt to add the usual CBOP / CEOP + standard format comments
it's really useful for debugging to have myTime and especially myIter
available withing the S/R. So i would suggest to add them as argument.
probably better to use 3. _d 0 and 4. _d 0 instead of just 3 and 4
in mom_visc_qgl_stretch.F (the only exception would be the power)
Note that these simple constant: zeroRL, oneRL, twoRL, halfRL
are defined in EEPARAMS.h and therefore available everywhere.
the "1. _d -9" constant is used in several places, so it might be better
to use a named constant for it (like QGL_epsil) in case one want to
change it (or test if it does make a difference).
Also, in mom_visc_qgl_limit.F, line 76, the "-9" is beyond 72 column.
Luckily, after CPP processing it got moved inside the 72.c so it's OK
but little bit risky.
in gmredi_calc_tensor.F, line 295, this will reset array GM_LeithQG_K
to zero nSx*nSy times (since it's within bi,bj loops). Not great and
could be confusing when running multi-threaded.

Algorithm:

main issue: the special code for k=1 and k=Nr is a problem, because
the bottom is not always at k=1 (in p-coords) or at k=Nr (in z-coords).
In addition, below an ice-shelf, the uppermost grid cell is not at k=1 in
z-coords (p-coords is not an issue since it's not working with pkg/shelfice).
I would argue that:
a) either this special treatment is really necessary, and in this case
it needs to be implemented for non-uniform kLowC (=Nr) and non-uniform
kSurfC (=1)
b) or this special treatment is not essential and current code give
good results even above kLowC < Nr, and in this case we should remove
the piece of code dealing with k=1 and k=Nr.
The idea is that the results are not expected to change if I increase
Nr by 1 and fill the bottom level with land.
In many places, computation is not right because it ignores the precise
location of variables on C-grid ; but since the exact location is not
clearly documented, I might have missed some.
a) computation of N2_2 (line 400 and above), should be recip_drC(k+1) ;
and not convinced that the right recip_dr is used in computation of N2_3 neither.
b) horizontal location of "stretching" is at grid-cell center ; this is
not consistent with lines 87-88 of mom_visc_qgl_limit.F since vort3 is
at grid-cell corner. Not consistent neither with computation of vrtDx & vrtDy
in mom_calc_visc.F (assumed to be at same location as vort3).
c) GM_LeithQG_K seems to be at grid-cell center (where Theta & Salt are)
but vertical averaging is missing when computing Kwx, Kwy and Kwz (in
gmredi_calc_tensor.F).
GM_useLeithQG is not implemented in gmredi_calc_psi_b.F ; however, it contributes
to the GM part when using the skew flux. This is a little bit strange.
Also, would it be difficult to implement a run-time switch to get QG-Leith only
for Redi or only for GM ?
And an open question: is there any need to implement GM_LeithQG_K in
gmredi_calc_psi_bvp.F ?
the code is not always safe regarding the risk of division by zero:
a) in mom_visc_qgl_stretch.F, could make sure that N2 is not negative,
using: MIN( zeroRL, sigmaR ) instead of just sigmaR
b) in mom_visc_qgl_limit.F, will not work when a grid-cell is centered on
the equator, because of division by fCori(i,j,bi,bj)**2 ; since the sign
does not matter, should be easy to fix using a max.
last thing: will need to add some check and stop but can consider this
later on.

Thanks @jm-c. I'm going to be working on this again in the next couple of weeks.
@septicscuzzy - do you have any comments on these?

Using limiters on N2 and fCori to prevent division by zero is entirely
sensible -- the QG theory breaks down at the equator and when the
stratification is really weak anyways, so we just need to handle these
situations in a minimally intrusive way.
On Mon, Sep 10, 2018 at 9:31 AM, Ed Doddridge notifications@github.com
wrote:

Thanks @jm-c https://github.com/jm-c. I'm going to be working on this
again in the next couple of weeks.
@septicscuzzy https://github.com/septicscuzzy - do you have any
comments on these?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-419956021, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATrzIujUp61aBXgo_trpo8b4uqUQ8tzmks5uZoXhgaJpZM4Txn35
.

@jm-c - I've been implementing your suggestions for tidying the code up. Mostly done, apart from the grid locations, which will take a bit longer.

the "1. _d -9" constant is used in several places, so it might be better
to use a named constant for it (like QGL_epsil) in case one want to
change it (or test if it does make a difference).

Were you imagining that this would be a proper runtime parameter that comes through the input files and has a default, or just a local variable that could be changed prior to compiling. I'm happy to implement it with all the bells and whistles, I'm just not sure how much use it would get.
@septicscuzzy - Cheers. I agree.
Do you have strong feelings or insights on @jm-c's more substantial comments?
Removing the special code for k=1 or k=Nr

Thoughts?
At the moment the main section in mom_visc_qgl_stretch.F calculates the vertical derivative as centred differences. With some clever masking we could use the exact same code to calculate a one sided difference at the top and bottom.

Having this available for only Redi or only GM?

My understanding is that adding QGLeith to GM is just a nice way of smoothing the fields, so it should work just as well for either Redi or GM. Am I missing something fundamental?

I'm glad jm-c looked through it in detail. I'm not surprised at most of his
points, as I was expecting some degree of slop in my original coding that
would need to be sorted out before the module became canon.  The details
regarding the "k=1, k=Nr" problem were things I was not aware of.  I think
doing one-sided differences is a good solution.  Regarding Redi/GM, the
theory is only validated for GM and we never explored what would happen if
you made it available to Redi too.  I don't think it would be a bad idea to
allow Redi = QGL too if that is what the user wants, with the caveat that
any effects from such a choice are unknown and undocumented.
On Mon, Sep 24, 2018 at 1:21 PM Ed Doddridge notifications@github.com
wrote:

@jm-c https://github.com/jm-c - I've been implementing your suggestions
for tidying the code up. Mostly done, apart from the grid locations, which
will take a bit longer.
the "1. _d -9" constant is used in several places, so it might be better
to use a named constant for it (like QGL_epsil) in case one want to
change it (or test if it does make a difference).
Were you imagining that this would be a proper runtime parameter that
comes through the input files and has a default, or just a local variable
that could be changed prior to compiling. I'm happy to implement it with
all the bells and whistles, I'm just not sure how much use it would get.
@septicscuzzy https://github.com/septicscuzzy - Cheers. I agree.
Do you have strong feelings or insights on @jm-c https://github.com/jm-c's
more substantial comments?
Removing the special code for k=1 or k=Nr

Thoughts?
At the moment the main section in mom_visc_qgl_stretch.F calculates
the vertical derivative as centred differences. With some clever masking we
could use the exact same code to calculate a one sided difference at the
top and bottom.

Having this available for only Redi or only GM?

My understanding is that adding QGLeith to GM is just a nice way of
smoothing the fields, so it should work just as well for either Redi or GM.
Am I missing something fundamental?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MITgcm/MITgcm/pull/96#issuecomment-424093882, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATrzIkRbSgIkmV1ThYPX5rWKDqv9-x5jks5ueTDVgaJpZM4Txn35
.

Next iteration:

main issue: the special code for k=1 and k=Nr is a problem, because
the bottom is not always at k=1 (in p-coords) or at k=Nr (in z-coords).
In addition, below an ice-shelf, the uppermost grid cell is not at k=1 in
z-coords (p-coords is not an issue since it's not working with pkg/shelfice).
I would argue that:
a) either this special treatment is really necessary, and in this case
it needs to be implemented for non-uniform kLowC (=Nr) and non-uniform
kSurfC (=1)
b) or this special treatment is not essential and current code give
good results even above kLowC < Nr, and in this case we should remove
the piece of code dealing with k=1 and k=Nr.
The idea is that the results are not expected to change if I increase
Nr by 1 and fill the bottom level with land.

Agreed. I've removed the special computations for k=1 and k=Nr. There is instead a series of IF statements that determines if we're at the top, in the middle, or at the bottom and sets some offsets to appropriate values. These offsets are then used within the main code so that it can handle each situation. I didn't end up using one sided differencing, because I needed to difference the slopes. In this implementation the top level gets the same viscosity as the one below it, and the bottom level the same as the one above it. This is a small change from @septicscuzzy's implementation where they got the same value as the one two below or above - is there a theoretical argument I'm missing that makes that a better choice?
One quirk is that the algorithm requires density above and below the level being evaluated in order to evaluate vertical derivatives of stratification. Obviously, this isn't possible at the top or the bottom. Rather than always calculate density at five separate levels (the level of the k loop, plus the ones either side for normal situations, and the ones immediately above and below those for the top and bottom cases) I've included calls to FIND_RHO_2D that return just the density in the required grid cell when the IF tree shows that we need density at an additional level.

In many places, computation is not right because it ignores the precise
location of variables on C-grid ; but since the exact location is not
clearly documented, I might have missed some.
a) computation of N2_2 (line 400 and above), should be recip_drC(k+1) ;

Yep. Fixed.

and not convinced that the right recip_dr is used in computation of N2_3 neither.

Yep. This one needs the sum of drC(k) and drC(k+1).

b) horizontal location of "stretching" is at grid-cell center ; this is
not consistent with lines 87-88 of mom_visc_qgl_limit.F since vort3 is
at grid-cell corner.

I've averaged vort3 to the cell centres so that it's at the same place as the other terms used to limit stretching.

Not consistent neither with computation of vrtDx & vrtDy
in mom_calc_visc.F (assumed to be at same location as vort3).

I think vrtDx is at the v-points and vrtDy is at the u-points. I've altered the QGLeith code so that the gradients of `stretching are averaged onto these same points.

c) GM_LeithQG_K seems to be at grid-cell center (where Theta & Salt are)
but vertical averaging is missing when computing Kwx, Kwy and Kwz (in
gmredi_calc_tensor.F).

Indeed. GM_LeithQG_K is now vertically averaged for Kwx, Kwy, and Kwz.

GM_useLeithQG is not implemented in gmredi_calc_psi_b.F ; however, it contributes
to the GM part when using the skew flux. This is a little bit strange.

Good point. I've included it in gmredi_calc_psi_b.F. I had to also pass myTime and myIter to GMREDI_CALC_PSI_B since GMREDI_CALC_QGLEITH requires them as arguments.

Also, would it be difficult to implement a run-time switch to get QG-Leith only
for Redi or only for GM ?

Given @septicscuzzy's comment:

Regarding Redi/GM, the theory is only validated for GM and we never explored what would happen if you made it available to Redi too.  I don't think it would be a bad idea to allow Redi = QGL too if that is what the user wants, with the caveat that any effects from such a choice are unknown and undocumented.

It doesn't seem like a great idea to just code it up for the sake of coding it - if we have no idea what it will do, or whether it's a good idea to do it, why put it in?

And an open question: is there any need to implement GM_LeithQG_K in
gmredi_calc_psi_bvp.F ?

I've never used that routine, but from memory, it doesn't allow for variable kappa_GM schemes like Visbeck, does it? So, probably no need to implement this?

the code is not always safe regarding the risk of division by zero:
a) in mom_visc_qgl_stretch.F, could make sure that N2 is not negative,
using: MIN( zeroRL, sigmaR ) instead of just sigmaR
b) in mom_visc_qgl_limit.F, will not work when a grid-cell is centered on
the equator, because of division by fCori(i,j,bi,bj)**2 ; since the sign
does not matter, should be easy to fix using a max.

I've implemented both of those.

last thing: will need to add some check and stop but can consider this
later on.

OK, let's chat.
Still to do:

[ ] There's a floating point exception (IEEE_INVALID_FLAG) that I haven't tracked down yet.
[ ] These changes alter the results of the test simulations. Given that I've shifted variables on the grid and altered the algorithm, that's expected, but requires validation. We need to run some bigger simulations and analyse the output.

@edoddridge going to talk to you about way to skip recomputing density (call to EOS).
also noticed:
a) myTime is declared INTEGER but  should be _RL
b) in mom_calc_visc.F, line 437, leithQG2fac should be inside SQRT function.
In general, thecurrent  implementation of QG-Leith does not zero out gradient between land point
and ocean point.

When computing stretching term,  if should be possible to make sure the stretching is right
near bottom & surface for the case of uniform stratification.
regarding horizontal gradient of stretching, since stencil is much wider that original one (with only
grad of vorticity involved), might be better to zero out (multiply by maskW & maskS) the gradient
that involve land point.

@jm-c - these latest commits avoid recomputing density by using sigmaRfield from DYNVARS.h. The storage is protected by cpp options.
When dealing with vertical locations, the edge cases are dealt with more elegantly now:

one level of ocean: stretching is set to zero
two levels of ocean, in the upper level: use stratification from lower face of tracer cell, assume it is constant in the vertical
two levels of ocean, in the lower level: use stratification from the upper face of tracer cell, assume it is constant in the vertical

Regarding masking the horizontal gradients, the gradient of stretching is set to zero based on maskS:
https://github.com/MITgcm/MITgcm/blob/ab507001dda4f4ddb7a52a2ff6598c5853717efc/pkg/mom_common/mom_calc_visc.F#L333-L343
and maskW:
https://github.com/MITgcm/MITgcm/blob/ab507001dda4f4ddb7a52a2ff6598c5853717efc/pkg/mom_common/mom_calc_visc.F#L353-L365
(sorry for all the noise on this branch)

@edoddridge I started to check the changes/addition to pkg/gmredi ; I saw some problems so I made
few adjustments there. I might do other minor update to reduce number of difference with original code
(since it helps to find problems). I have few suggestions:

we don't need to support QG-Leith in GM for the case where "GM_NON_UNITY_DIAGONAL" is undef;
Just adding a "stop" in gmredi_check.F for this case should do it; with this restriction, we don't need to change gmredi_xtransport.F &gmredi_ytransport.F  (and BTW, we need also a stop when GM_useLeithQG=T but ALLOW_GM_LEITH_QG is undef).
shorter experiments name ? I would drop "Ah" since there is no bi-harmonic version;
maybe: MLAdjust.QGLeith and MLAdjust.GQLthGM ?
maybe there is a problem in: MLAdjust/input.AhLeithQG_GM/data.gmredi
with GM_useBVP=T since I don't see QG-Leith being implemented in BVP routine.

@edoddridge I think there is still one remaining problem: Nsquare from output of S/R mom_visc_qgl_stretch.F is at vertical interface k, between level k-1 and level k. But inside S/R mom_visc_qgl_limit.F, it is assumed to be at level center k. May be simplest would be to vertically average Nsquare inside mom_visc_qgl_stretch.F (with all 3 cases) ?
And 2 comments on the side:
a) it might be possible to simplify a bit mom_visc_qgl_limit.F, skipping SQRT function and removing
few **2 or **4 calculation.
b) related to above: might be good to explicitly add description of the grid location of new variables
GM_LeithQG_K, Nsquare, streching (+ may be few others that I might missed).
Currently re-running full set of ADM & FWD experiments.

@edoddridge there are 2 experiments (1 fwd, 1 adm) that do not compile, likely because of my changes. Going to check this.

Should be better now: both experiments tutorial_cfc_offline and tutorial_dic_adjoffline are passing. Have not
checked  the OpenAD testreport but will wait until final update are done.

Thanks @jm-c.
I rolled back the changes in gmredi_xtransport.F and gmredi_ytransport.F and put in a stop for when GM_NON_UNITY_DIAGONAL is undef.
I also put in a STOP for the case in which ALLOW_GM_LEITH_QG is undef and GM_useLeithQG=T, but the model doesn't get that far. It hits a STOP in pkg/diagnostics because GM_LTHQG isn't defined:
runmodel in MLAdjust/tr_run.QGLthGM ... failed (run: 0  end: 0 )
=> output from running in MLAdjust/tr_run.QGLthGM :
>  link mitgcmuv from dir ../build
> STOP ABNORMAL END: S/R DIAGNOSTICS_SET_POINTERS
> DIAGNOSTICS_SET_POINTERS: GM_LTHQG is not a Diagnostic

I dropped the "Ah" from the verification experiments and shortened the names. Good suggestion.
You're right - I shouldn't have used the BVP formulation of GM. QGLeith doesn't work with that form. It's fixed now.
I averaged Nsquare in the first case, but didn't for either of the top or bottom scenarios. At the top and the bottom, I made the algorithm assume the stratification is constant, so I just made sure that the array Nsquare gets given the right value.
Good point about mom_visc_qgl_limit.F. I removed the SQRT and carried around the squared value, which removes some computation.
I added some comments about grid location of the new variables.
I realised that I hadn't averaged the stretching gradient correctly in gmredi_calc_qg_leith.F. That's been fixed.
I'm currently running testreport (forward experiments only) on my laptop.

All the forward tests compile and run. There are a few where the output differs enough from the stored outputs that I get  a "FAIL", but those simulations also fail when I run testreport on master, so it's not related to these changes.
I'm going to merge master into this branch so I can add the new parameters to the table in chapter 3.

@edoddridge I checked that all OpenAD experiments are unaffected (after fixing the little syntax error).
Regarding the 2 new experiment output, there is one annoying thing is that on our reference platform
(baudelaire) results are little bit different (11 digits are similar) ; so it means we will need to get a new version from baudelaire itself.
And also one comment regarding: 7b627fde0ee0da4e630adeb31c3b3b1aa2a4d65e
the magnitude of QGL_lim_epsil has not been changed (now used with squared of N2*dz ).  It might be better to put a smaller value (square of current one ?) since typical value of N2 or f are not that large.

That's annoying - I guess you'll need to commit the output from baudelaire.
Two minor fixes:

reduce QGL_epsil to the square of the previous value
I implemented the same fix as e3b891cdca00e73ef51f326fe648e7894748f05d in the GM subroutine.

Forgot to comment after updating output: Everything looks good.
LGTM +1

Thanks @septicscuzzy
@jrscott - does this mean that the docs have your blessing?

thx @septicscuzzy, that makes more sense, fixed.

authors: dfer22 edoddridge jm-c jrscott septicscuzzy


text:
就论文的复现有几个问题想请教一下

作者 你好，这篇文章融合不同尺度的特征图来获取更好的结果，我觉得很受启发。所以我尝试着复现论文中的结果，下面这个是现在正在跑的结果。
epoch 17
Avg bicubic psnr = 33.691134694590936
Avg predicted psnr = 37.55205991379186
Avg bicubic ssim = 0.8475448663228888
Avg predicted ssim = 0.8952058433758587

因为实验室的设备问题，DIV2K这样大的数据集跑不了，所以我仅仅将训练集换成了那291张图片，其他没做改变。所以我想问一下，这样的改变会对PSNR产生多大的影响，我测试了一下，图片x2的情况，epoch到9达到了极大值37.63，现在到了epoch17，徘徊在37.5左右。源代码是20epoch，我想问一下，你觉得还有必要跑下去吗？
在做test的时候，SSIM明显是不对的，数据在上面。所以我想问是不是代码出了问题，还是我的设备出了问题。
希望得到作者的解答，谢谢！

您好，感谢对我们论文的关注。
我不确定你使用的是我们提供的旧代码还是新代码？
我们没有使用291作为训练集训练过网络，所以我不确定你们的结果是否正确。但根据我们的经验，数据集的质量和数量会很大程度影响模型最后的结果。对于一个参数较多的模型，训练集偏少会导致网络没有得到充分的训练。我们提供的旧代码中，使用MATLAB代码预处理DIV2K数据集并生成一个总的.h5文件。这个.h5文件高达几百个G，这对于你的设备来说可能负担是巨大的。因此，我们参照了EDSR开源的代码，提供了一份关于MSRN新的可运行代码，该份代码也采用DIV2K作为训练集，但是在数据处理和读取方面，EDSR的作者做了很好的处理，所以你无需很好的设备也可以正常运行该实验。我们按照EDSR提供的代码，重写了MSRN，并且重新训练该网络，得到的结果与我们ECCV论文上的结果是接近的。在3、4倍上甚至达到了更好的结果。与旧代码不同的是，新代码与近期SR的工作一样，都是直接在RGB3通道上进行训练的。而在测试阶段，我们只测试了图像在Y通道上的PSNR和SSIM。

作者你好 新版本的代码里的trainer.py中的28行左右for _ in range(len(ckp.log)): self.scheduler.step()这行是不是有问题，学习率好像不是中断训练之前的那个学习率了，继续训练的学习率变得更小了
希望得到作者的解答，谢谢！

您好，我不是原文的作者，另外我复现论文的时候是在old版本上进行的。新版本是在EDSR的主框架上修改的，在old的里面，学习率就有衰减，所以学习率就是会变小的。
---原始邮件---
发件人: "Areil"<notifications@github.com>
发送时间: 2019年10月15日(星期二) 晚上7:06
收件人: "MIVRC/MSRN-PyTorch"<MSRN-PyTorch@noreply.github.com>;
抄送: "Author"<author@noreply.github.com>;"breezero1994"<1109080397@qq.com>;
主题: Re: [MIVRC/MSRN-PyTorch] 就论文的复现有几个问题想请教一下 (#4)
作者你好 新版本的代码里的trainer.py中的28行左右for _ in range(len(ckp.log)): self.scheduler.step()这行是不是有问题，学习率好像不是中断训练之前的那个学习率了，继续训练的学习率变得更小了
希望得到作者的解答，谢谢！
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

不好意思，没看懂你这句话想要表达什么“学习率好像不是中断训练之前的那个学习率了，继续训练的学习率变得更小了”

就是这里面https://blog.csdn.net/sinat_31987445/article/details/94736301提到的第二个问题，他提到学习率异常，但是我测试了下学习率好像没问题，所以就来问问作者

每次运行的时候都会打印出学习率，这个学习率是真实的，你看看每次打印出来的学习率是否正确就是。我看了你提供链接的博士，他在更高版本的pytorch上运行这份代码，pytorch不向下兼容，可能会导致一系列问题。

每次运行的时候都会打印出学习率，这个学习率是真实的，你看看每次打印出来的学习率是否正确就行。我看了你提供链接的博主，他在更高版本的pytorch上运行这份代码，pytorch不向下兼容，可能会导致一系列问题。

source: gharchive/issue

authors: CV-JunchengLi breezero1994 userzm

repo: MIVRC/MSRN-PyTorch

license: MIT

license_type: permissive

license_source: github-api


text:
refer to document symbols in chat window

As a user i would like to be able to refer to document symbols when chatting by typing something like @fibonacci and then automatically exchanging it for a function, method or whatever when prompting

Could make use of https://neovim.io/doc/user/lsp.html#vim.lsp.buf.document_symbol()


text:
Remove unnecessary and unused react artifacts from code base

Some artefacts are imported from the react library but are not used.
It would be nice to remove them and clean up the codebase.
This would make the code base cleaner.

@NoahCardoza
Could you please assign this to me and @EkjotKaur

Good catch!

authors: NoahCardoza obasekiosa


text:
Pagina primeros cambios

Realizé los siguientes cambios:
-Actualicé el index con la info y links de las secciones correspondientes.
-Agregué imagénes para el Index que pueden ser cambiadas en dado caso de que no sea de su agrado total.
-Agregué las páginas de las secciones de interés y todo listo para que empicen a trabajar en ellas.

Se puede consultar el resultado en GitHub Pages

source: gharchive/pull-request


text:
Improve regexp pattern for matching negative values in viewbox attribute

Negative values weren't matched (despite being valid) in viewBox svg attribute.
This fix a build fail when no value were inserted in place of viewbox key in each generated icons

Coverage remained the same at 100.0% when pulling c3a09eb3c3b8871b3b967037301a79c0eafdd021 on AlexandreBonaventure:patch-1 into 9c67f6f29a6281c807ba03e2a58598dd977989ef on MMF-FE:master.

authors: AlexandreBonaventure coveralls

repo: MMF-FE/vue-svgicon

license: mit

license_source: bigquery


text:
Expose block statistics via API

would it be possible to expose the basic elements of each block found via the API?
from this page in a MPOS instance
https://[pool_url]/index.php?page=statistics&action=round&height=####
Would it be possible to expose the following elements via the API?
ID	####	Height	####	Amount	#	Confirmations	### left
Difficulty	####	Time	YYYY-MM-DD HH:MM:SS	Shares	#### Finder	[user]

https://github.com/MPOS/php-mpos/blob/master/include/pages/api/getblocksfound.inc.php
Already there i would think. Try it out.

that works for the most recent blocks, would it be possible to be able to specify the height parameter on that page so one can pull details of less recent blocks?

Yeah should be possible. But maybe it should be it's own API call allowing to fetch one single block.

I am closing all old feature requests and ideas since it doesn't seem that anyone is doing a PR against those anyway. Since I won't have the time, no need to keep these ideas open if they are not eventually being implemented.

authors: TheSerapher zoomequipd

repo: MPOS/php-mpos


text:
fix P value for negative t

fix P value, very minor changes.  Please have a review @swashcap

:+1: Looks great! 🎉


text:
LogSink depends on the IVCT.properties

LogSink project depends on the IVCT_Conf ENV variable and the IVCT.properties file because it uses the Factory.initialize().
Is this really necessary, or can the LogSink use its own properties file to decouple LogSink from the other components to allow more simple containerized deployment.

Should be solved together with #102

not sure if it is a good idea to have multiple properties files. I would prefer to have only one initialization mechanism in all the JMS clients.
We need to harmonize the initialization mechanisms in all components.

move all parameters into use environment variables to support docker configuration.
If an application shall be started in native mode, use bat. files to initialize these variables.

While I was working on making a dockerfile for the LogSink I ran into this again.
Why does the LogSink need the IVCT.Properties. Doesn't it only need to know the activemq host/port and credentials?

The property values required by the test system are now done in the following order: environment variables,  IVCT.Properties file then internal default values. The description of these values is found in https://github.com/MSG134/IVCT_Framework/wiki/IVCT_Configuration. Thus the test system can now be run without a IVCT.Properties file: use environment variables instead.

authors: PHameete ducana rhzg


text:
Import button is enabled even if no file is selected

While Importing the Subscription (publish setting file), if we giving 'Blank file location' or 'edit the file name' after browsing, the 'import' button should be disabled.
PFB the screen shot

This issue is reproducible when the user selects wrong file.
PFB the screen shot.

This issue is fixed and working as expected in the latest build.


text:
YouTubeads模块在最新测试版Surge下失效

pip功能用不了，广告好像也不去不了
Surge版本如图：

Surge 在 TF 5.21.0(2887) 中默认开启了 TUN 模式，导致视频播放的请求走了 QUIC 协议。
现在模块中新增了一条规则，更新最新模块后将恢复正常。

authors: DockerCS Maasea

repo: Maasea/sgmodule


text:
maatwebsite multiple sheets mapping data show wrong[BUG]

Prerequisites

[ ] Checked if your Laravel Excel version is still supported: https://docs.laravel-excel.com/3.1/getting-started/support.html#supported-versions
[ ] Able to reproduce the behaviour outside of your code, the problem is isolated to Laravel Excel.
[ ] Checked that your issue isn't already filed.
[ ] Checked if no PR was submitted that fixes this problem.
[ ] Filled in the entire issue template

Versions

PHP version: 7,2
Laravel version: 7
Package version: 3.1

Description
I am creating multiple sheet. First sheet data mapping is working good and next page data full wrong data mapped
Controller Code:
 $id=57;
   return (new BugExport($id))->download('test.xlsx');

Export Code:
<?php

namespace App\Exports;

use App\Model\bug;
use Maatwebsite\Excel\Concerns\FromCollection;
use Maatwebsite\Excel\Concerns\Exportable;
use Maatwebsite\Excel\Concerns\ShouldAutoSize;
use Maatwebsite\Excel\Concerns\WithMapping;
use Maatwebsite\Excel\Concerns\FromArray;
use Maatwebsite\Excel\Concerns\WithMultipleSheets;
class BugExport implements WithMultipleSheets
{
    use Exportable;
    /**
    * @return \Illuminate\Support\Collection
    */
    protected $id;
    public function __construct(int $id)
    {
        $this->id = $id;
    }
    public function sheets(): array
    {
        $sheets = [];
        $array_value=['Bugs','Bug Activities','Bug Comments'];
        $sheets[] = new Bugs($this->id, $array_value[0]);
         $sheets[] = new Bug_Activitie($this->id, $array_value[1]);

        return $sheets;
    }

}

Bug Activities Code:
<?php

namespace App\Exports;
use Maatwebsite\Excel\Concerns\FromCollection;
use Maatwebsite\Excel\Concerns\Exportable;
use Maatwebsite\Excel\Concerns\ShouldAutoSize;
use Maatwebsite\Excel\Concerns\WithMapping;
use Maatwebsite\Excel\Concerns\FromArray;
use Maatwebsite\Excel\Concerns\FromQuery;
use App\Model\bug;
use Maatwebsite\Excel\Concerns\WithTitle;
use Maatwebsite\Excel\Concerns\WithHeadings;
use Maatwebsite\Excel\Concerns\WithEvents;
use Maatwebsite\Excel\Events\AfterSheet;

class Bug_Activitie implements FromCollection,WithTitle,
ShouldAutoSize,WithHeadings,WithEvents
{

    private $id;
    private $sheet_name;
    private $i = 1;
    public function __construct(int $id, string $sheet_name)
    {
        $this->sheet_name = $sheet_name;
        $this->id  = $id;
    }

    /**
    * @return \Illuminate\Support\Collection
    */
    public function collection()
    {
        //
        return bug::with('bug_activities')
        ->where('project_id',$this->id)->get();
    }

     /**
     * @return Builder
     */
    public function query()
    {

        return bug::query()->with('bug_activities')
       ->where('project_id',$this->id)->get();
       //echo "
1";print_r($test);die;

    }

    public function title(): string
    {
        return  $this->sheet_name;
    }

    public function map($bug): array
    {
       // echo 1;die;

        echo "
Navin";print_r($bug);die;
        return [

            !empty($bug->bug_activities[$this->i]->id)?$bug->bug_activities[$this->i]->id:'',
            !empty($bug->bug_id)?$bug->bug_id:'',
            !empty($bug->bug_activities[$this->i]->activity)?$bug->bug_activities[$this->i]->activity:'',
           !empty($bug->bug_activities[$this->i]->created_at)?date('M-d-Y',strtotime($bug->bug_activities[$this->i]->created_at)):'',
           // date('M-d-Y',strt otime($bug->created_at)),

        ];
        $this->i++;
    }

    public function headings(): array
    {
        return [
            //'#',
            'Bug Id',
            'User Name',
            'Activities',
            'Created Date'

        ];
    }

}

Steps to Reproduce

Expected behavior:
Array
(
[0] => Array
(
[id] => 8
[bug_id] => BK-931062
[user_id] => 37
[activity] => The Bug is Open on BK-931062
[created_at] => 2020-07-17T17:38:06.000000Z
[updated_at] => 2020-07-17T17:38:06.000000Z
[status] => 1
[user_name] => Naveen
)
[1] => Array
    (
        [id] => 9
        [bug_id] => BK-397174
        [user_id] => 39
        [activity] => The Bug is Open on BK-397174
        [created_at] => 2020-07-17T17:46:45.000000Z
        [updated_at] => 2020-07-17T17:46:45.000000Z
        [status] => 1
        [user_name] => Demo Naveen
    )

[2] => Array
    (
        [id] => 12
        [bug_id] => BK-556095
        [user_id] => 37
        [activity] => The Bug is Open on BK-556095
        [created_at] => 2020-07-17T18:06:46.000000Z
        [updated_at] => 2020-07-17T18:06:46.000000Z
        [status] => 1
        [user_name] => Naveen
    )

[3] => Array
    (
        [id] => 13
        [bug_id] => BK-556095
        [user_id] => 37
        [activity] => The Bug is Reassign to Naveen
        [created_at] => 2020-07-17T18:07:50.000000Z
        [updated_at] => 2020-07-17T18:07:50.000000Z
        [status] => 1
        [user_name] => Naveen
    )

[4] => Array
    (
        [id] => 16
        [bug_id] => BK-731281
        [user_id] => 39
        [activity] => The Bug is Open on BK-731281
        [created_at] => 2020-07-17T18:13:51.000000Z
        [updated_at] => 2020-07-17T18:13:51.000000Z
        [status] => 1
        [user_name] => Demo Naveen
    )

[5] => Array
    (
        [id] => 17
        [bug_id] => BK-731281
        [user_id] => 37
        [activity] => The Bug Status Changed into In Progress
        [created_at] => 2020-07-17T18:20:29.000000Z
        [updated_at] => 2020-07-17T18:20:29.000000Z
        [status] => 1
        [user_name] => Naveen
    )

[6] => Array
    (
        [id] => 18
        [bug_id] => BK-731281
        [user_id] => 37
        [activity] => The Bug is Reassign to Demo Naveen
        [created_at] => 2020-07-17T18:21:04.000000Z
        [updated_at] => 2020-07-17T18:21:04.000000Z
        [status] => 1
        [user_name] => Naveen
    )

[7] => Array
    (
        [id] => 19
        [bug_id] => BK-731281
        [user_id] => 39
        [activity] => The Bug is Reassign to Naveen
        [created_at] => 2020-07-17T18:32:26.000000Z
        [updated_at] => 2020-07-17T18:32:26.000000Z
        [status] => 1
        [user_name] => Demo Naveen
    )

[8] => Array
    (
        [id] => 20
        [bug_id] => BK-731281
        [user_id] => 39
        [activity] => The Bug is Reassign to Demo Naveen
        [created_at] => 2020-07-17T18:33:53.000000Z
        [updated_at] => 2020-07-17T18:33:53.000000Z
        [status] => 1
        [user_name] => Demo Naveen
    )

)
This data need to mapping in bug_activities
Actual behavior:
nApp\Model\bug Object
(
[table:protected] => bugs
[dates:protected] => Array
(
[0] => created_at
[1] => updated_at
)
[connection:protected] => mysql
[primaryKey:protected] => id
[keyType:protected] => int
[incrementing] => 1
[with:protected] => Array
    (
    )

[withCount:protected] => Array
    (
    )

[perPage:protected] => 15
[exists] => 1
[wasRecentlyCreated] =>
[attributes:protected] => Array
    (
        [bug_id] => BK-931062
        [user_name] => Naveen
        [activity] => The Bug is Open on BK-931062
        [created_at] => 2020-07-17 17:38:06
    )

[original:protected] => Array
    (
        [bug_id] => BK-931062
        [user_name] => Naveen
        [activity] => The Bug is Open on BK-931062
        [created_at] => 2020-07-17 17:38:06
    )

[changes:protected] => Array
    (
    )

[casts:protected] => Array
    (
    )

[classCastCache:protected] => Array
    (
    )

[dateFormat:protected] =>
[appends:protected] => Array
    (
    )

[dispatchesEvents:protected] => Array
    (
    )

[observables:protected] => Array
    (
    )

[relations:protected] => Array
    (
    )

[touches:protected] => Array
    (
    )

[timestamps] => 1
[hidden:protected] => Array
    (
    )

[visible:protected] => Array
    (
    )

[fillable:protected] => Array
    (
    )

[guarded:protected] => Array
    (
        [0] => *
    )

)

This export page query return correct values but mapping show irrelevant data

Additional Information
NA

I don't understand the issue. You are getting an Eloquent Bug model in the map method, that's expected behaviour... ?

@patrickbrouwers. The issue is The query is returning correct in FromCollection method and mapping also came same value right?

in collection() you are selecting columns which means it won't return an eloquent model, if you use query() it will return an eloquent model. Choose one or the two that fits your needs, but I don't see any bug.

@patrickbrouwers collection() i call get() function still mapping irreverent record.

I don't know then, if you think it really is a bug in our package, please provide a minimal reproduction situation in a failing unit test or example repository that I can run on my computer.

authors: navaneetharajan patrickbrouwers

repo: Maatwebsite/Laravel-Excel


text:
"Missing ./redis specifier in package"

I tried it on StackBlitz, to assure it doesn't come from my config, but I can't use Redis a session storage.
I get this weird error when I run vite dev :
Error: Missing "./redis" specifier in "@macfja/sveltekit-session" package
    at e (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:14893:25)
    at n (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:14893:627)
    at o (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:14893:1276)
    at resolveExports (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:22081:21)
    at resolveDeepImport (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:22100:45)
    at tryNodeResolve (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:21785:20)
    at resolveId (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:21536:28)
    at resolveId (file://file:///home/projects/sveltejs-kit-template-default-dn9q2j/node_modules/vite/dist/node/chunks/dep-ca21228b.js:41660:46)
    at <anonymous> (<anonymous>)

You can reproduce it on the stackblitz I shared. If you have any clue :pray:

Apparently it was a known bug, fixed in 1.6.0. I'll check later if it works now

Keep me in touch if it solved your issue

Still not working with SvelteKit 1.10.0 :-(
The stack trace is slightly different, but it seems that redis is in fault.
I saw in your package.json that @redis/client was in dev dependencies rather than in dependencies. Maybe it's the reason of this bug ?

authors: IT-ess MacFJA

repo: MacFJA/sveltekit-session


text:
Main thread not in main loop

Happens when we try to plot.
Seems to happen randomly, or after trying to plot with wrong inputs.
Sometimes, the newly requested plot will appear despite this error message (if one is patient enough), sometimes it won't.
For now => restart the server
Open forum post
https://discourse.mcneel.com/t/hops-wishes-or-available-options/131153

https://stackoverflow.com/questions/49921721/runtimeerror-main-thread-is-not-in-main-loop-with-matplotlib-and-flask
That triggers
"""UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
plt.show()"""


text:
🛑 Libreddit (libreddit.spike.codes) is down

In 08d33ef, Libreddit (libreddit.spike.codes) (https://libreddit.spike.codes) was down:

HTTP code: 404
Response time: 11045 ms

Resolved: Libreddit (libreddit.spike.codes) is back up in 3fada1e after 56 minutes.

repo: Magic-Services/upptime


text:
Update readme.md

Don't be political

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: cloudw233 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

No. Won’t fix this.


text:
Uncaptured query params

Hello!
I have got an API with multiple models. I'd like to to implement filters in my handler which would look like this:
GET /api/pets?name.eq=buddy&age.lt=5. Here I'm trying to get all pets named buddy younger than 5 years. There are two problems: my parameter names are not valid python identifiers(yet it could be solved by using _ delimiter). If first problem is solved, the second is lots of combinations to field_name.filter_type to list and they should be listed for every model I would like to filter.
It would be more convenient for me to get all query parameters not captured by keyword arguments, to handle it by myself later. Like this
class Pet(PydanticView):
    def get(self, **filters: str):
        pets = PetModel.filter(filters)
        ....

But It turns out there's no way to express it in my handler signature right now.
In swagger json it looks like this:
{
  "paths": {
    "/api/pets": {
      "get": {
        "parameters": [
          {
            "in": "query",
            "name": "filter",
            "schema": {
              "$ref": "#/components/schemas/FilterQuery"
            },
            "style": "form",
            "explode": true,
            "description": "Filter fields by eq(==), ne(!=), lt(<), le(<=), gt(>), ge(>=) methods",
            "required": false
          }
        ]
      }
    }
  },
  "components": {
    "schemas": {
      "FilterQuery": {
        "type": "object",
        "properties": {
          "param": {
            "type": "string",
            "default": "value"
          }
        },
        "example": {
          "name": "string",
          "id.ge": 1,
          "id.ne": 2,
          "created_at.gt": "2012-12-12T12:12:12+00:00",
          "updated_at.lt": "2021-12-12T12:12:12+00:00"
        }
      }
    }
  }
}

Hello, did you try to use the Group.
class AgeFilter(Group):
    age_gt: int = 0
    age_lt: int = 99

class Pet(PydanticView):
    def get(self, name: AgeFilter):
        pets = PetModel.filter(**name.to_dict())
        ....

https://github.com/Maillol/aiohttp-pydantic#group-parameters
I like the idea to have parameters with a dot such as client.name.eq, returning nested group. I think I will made a feature to aiohttp-pydantic 2

Yes, groups are great and actually I use them as workaround right now. But this is where problem #2 strikes. If Pet model has 10 fields and I use 6 filters(eq(==), ne(!=), lt(<), le(<=), gt(>), ge(>=)) than my group contains 60 combinations. So I came to crafting PetFilter from Pet model:
def generate_filters_for_model(model_type):
    # some type creation magic
PetFilter = generate_filters_for_model(Pet)
StoreFilter = generate_filters_for_model(Store)
UserFilter = generate_filters_for_model(User)

Each of these filter instances are used for nothing but compiling them to ORM statements. So they are processed by generic code which could operate with simple dict. I believe that additional classes are redundant in this case. Moreover swagger web page is bloated.
My original thought was that having some way to capture undefined query parameters solves both problems I've mentioned. Also it could be useful in other cases, not only filtering.

authors: Maillol almaslov

repo: Maillol/aiohttp-pydantic


text:
chore(CSharp): added radix sort

PR Checklist:

[x] My submission is formatted according to the guidelines in the contributing guide
[ ] My addition is on refer on the language README.md file
[x] My addition does not have a spelling problem
[x] My submission has a proper and user-friendly description of the algorithm
[ ] My submission has the time complexity of the algorithm
[x] My submission has sample input-output of the program (NOT FOR PYTHON)

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] New algorithm
[ ] Optimization in previous algorithms
[ ] Code style update
[ ] Refactor
[ ] Documentation
[ ] Other, please describe:

Briefly describe the changes in this PR

Other information:

Ok I will look into it.
On Thu, Dec 1, 2022 at 2:43 AM Waqar Hassan Khan @.***>
wrote:

@.**** requested changes on this pull request.
You need to write test-cases. Please follow the other test cases for C# to
write test cases
—
Reply to this email directly, view it on GitHub
https://github.com/MakeContributions/DSA/pull/1086#pullrequestreview-1200020215,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AV6MFECAVL2EQQDHWINR3IDWK67QFANCNFSM6AAAAAASIDM4FY
.
You are receiving this because you were assigned.Message ID:
@.***>

@Adi-ty why have you closed the PR?

repo: MakeContributions/DSA


text:
🛑 Open Weather API is down

In 8097812, Open Weather API (https://api.openweathermap.org/data/2.5/uvi?appid=$API_OPEN_WEATHER&lat=52.370216&lon=4.895168) was down:

HTTP code: 504
Response time: 2112 ms

Resolved: Open Weather API is back up in 1a9f5ec after 7 minutes.

repo: MamonakuCommittee/status


text:
🛑 World Weather Online API is down

In 62d89c7, World Weather Online API (https://api.worldweatheronline.com/premium/v1/marine.ashx?key=$API_WORLD_WEATHER_ONLINE&q=52.370216,4.895168&tide=no&fx=yes&tp=1&format=json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: World Weather Online API is back up in 82b0aff.


text:
Styling the page - Artist

Title, subtitle, content, buttons, image

We will be updating the UI of our application to match this Figma design on page "Prototype web".
To accomplish this, we need to create a <ArtistSection> component and add it to our Home page component. This Artist Section should have:

A white background
The title in Roboto Bold 48, black
The subtitle in Roboto Medium 24, black
Body content in Roboto Regular 16
The image (download from Figma)
A link to Learn more that points to the UCC PhD Student Website
A link to Get in touch that points (for now) to her LinkedIn
Flexbox styling

To see the styling information for the page, activate Figma's Dev Mode in the top righthand corner:

This design is desktop-first, so we will review mobile designs later in the week.

@gregdyke , you or perhaps I should validate this with Derdrie.
Is this the best photo?
What actual links are needed?
Does she have comments on the Figma in general?

authors: TianshengC mferryRV rogerspooner

repo: ManSangSin/Rhythm-Code

license: ISC


text:
Splitting the GraphQL OpenAPI description

Moving the GraphQL Response into a separate schema definition as the client generator was getting confused with the inline response definition.

@miq-bot assign @bdunne

Do consumers need to be updated to call the new method to get the response object?

authors: abellotti bdunne

repo: ManageIQ/manageiq-api-common


text:
Update selinux rules for cockpit

This was tested on the Aug 4th appliance. Most of this is needed by ruby on start up.

This is a bit tough to parse on first glance.
Can you give a description of the changes and why they are needed, or better yet, just link to some cockpit installation documentation which has these answers?

The changes are to allow the ruby script (https://github.com/ManageIQ/manageiq/blob/master/tools/cockpit/cockpit-auth-miq) to to run in the cockpit_ws_t context. That script is invoked by cockpit-ws to authenticate against remote machines.
These are not permissions that cockpit-ws normally needs, because normally it doesn't need to invoke ruby scripts. Most of this is ruby looking for paths and gems and then connecting to the drb service. The alternative is to mark cockpit-ws the same way as the rest of the ruby scripts. But that grants way more permissions than this does, and since miq processes on the appliance seem to run as root, I think this is a safer option.

Gregg I am assigning this to you for visibility. Cockpit integration is blocked on this.
@miq-bot assign gtanzillo

authors: carbonin petervo simon3z

repo: ManageIQ/manageiq-appliance


text:
[Changelog] Update for Sprint 75

[skip ci]

@miq-bot add_label documentation


text:
Add controller prefix to disk location column

This fixes rhev tests that were broken when the infra manager parser it inherits from was changed to include the controller prefix to the disk location.
See: https://github.com/ManageIQ/manageiq-providers-ovirt/pull/662
FYI, it's been several days since CI ran but this is what was failing locally:
  1) ManageIQ::Providers::Redhat::InfraManager::Refresher will perform a full refresh on v4.1
     Got 3 failures from failure aggregation block "tests".
     # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:19:in `block (2 levels) in <main>'
     # /Users/joerafaniello/.gem/ruby/3.1.4/gems/webmock-3.23.0/lib/webmock/rspec.rb:39:in `block (2 levels) in <main>'

     1.1) Failure/Error:
            expect(disk).to have_attributes(
              :device_name     => "GlanceDisk-fe03ebf",
              :device_type     => "disk",
              :controller_type => "virtio",
              :present         => true,
              :filename        => "08b054b2-0001-4dd6-9cf2-434213c02fbe",
              :location        => "0",
              :size            => 8_589_934_592,
              :size_on_disk    => 2_561_437_696,
              :mode            => "persistent",

            expected #<Disk id: 1000000000678, device_name: "GlanceDisk-fe03ebf", device_type: "disk", location: "0:0", fi...backing_type: nil, storage_profile_id: nil, bootable: true, ems_ref: nil, thin: true, format: "cow"> to have attributes {:controller_type => "virtio", :device_name => "GlanceDisk-fe03ebf", :device_type => "disk", :filename => "08..., :present => true, :size => 8589934592, :size_on_disk => 2561437696, :start_connected => true, :thin => true} but had attributes {:controller_type => "virtio", :device_name => "GlanceDisk-fe03ebf", :device_type => "disk", :filename => "08..., :present => true, :size => 8589934592, :size_on_disk => 2561437696, :start_connected => true, :thin => true}
            Diff:
            @@ -3,7 +3,7 @@
             :device_type => "disk",
             :filename => "08b054b2-0001-4dd6-9cf2-434213c02fbe",
             :format => "cow",
            -:location => "0",
            +:location => "0:0",
             :mode => "persistent",
             :present => true,
             :size => 8589934592,

          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:510:in `assert_specific_vm_powered_on'
          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:26:in `block (3 levels) in <main>'

     1.2) Failure/Error:
            expect(disk).to have_attributes(
              :device_name     => "GlanceDisk-34bec3e",
              :device_type     => "disk",
              :controller_type => "virtio",
              :present         => true,
              :filename        => "738dc6a9-c7ff-4bd4-8f37-d0e4fdc0ff76",
              :location        => "0",
              :size            => 46_137_344,
              :size_on_disk    => 204_800,
              :mode            => "persistent",

            expected #<Disk id: 1000000000677, device_name: "GlanceDisk-34bec3e", device_type: "disk", location: "0:0", fi...backing_type: nil, storage_profile_id: nil, bootable: true, ems_ref: nil, thin: true, format: "cow"> to have attributes {:controller_type => "virtio", :device_name => "GlanceDisk-34bec3e", :device_type => "disk", :filename => "73...stent", :present => true, :size => 46137344, :size_on_disk => 204800, :start_connected => true, :thin => true} but had attributes {:controller_type => "virtio", :device_name => "GlanceDisk-34bec3e", :device_type => "disk", :filename => "73...stent", :present => true, :size => 46137344, :size_on_disk => 204800, :start_connected => true, :thin => true}
            Diff:
            @@ -3,7 +3,7 @@
             :device_type => "disk",
             :filename => "738dc6a9-c7ff-4bd4-8f37-d0e4fdc0ff76",
             :format => "cow",
            -:location => "0",
            +:location => "0:0",
             :mode => "persistent",
             :present => true,
             :size => 46137344,

          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:653:in `assert_specific_vm_powered_off'
          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:27:in `block (3 levels) in <main>'

     1.3) Failure/Error:
            expect(disk).to have_attributes(
              :device_name     => "GlanceDisk-34bec3e",
              :device_type     => "disk",
              :controller_type => "virtio",
              :present         => true,
              :filename        => "2d41b00f-d594-47dd-9148-931731ddf8ff",
              :location        => "0",
              :size            => 46_137_344,
              :size_on_disk    => 12_775_424,
              :mode            => "persistent",

            expected #<Disk id: 1000000000679, device_name: "GlanceDisk-34bec3e", device_type: "disk", location: "0:0", fi...backing_type: nil, storage_profile_id: nil, bootable: true, ems_ref: nil, thin: true, format: "cow"> to have attributes {:controller_type => "virtio", :device_name => "GlanceDisk-34bec3e", :device_type => "disk", :filename => "2d...ent", :present => true, :size => 46137344, :size_on_disk => 12775424, :start_connected => true, :thin => true} but had attributes {:controller_type => "virtio", :device_name => "GlanceDisk-34bec3e", :device_type => "disk", :filename => "2d...ent", :present => true, :size => 46137344, :size_on_disk => 12775424, :start_connected => true, :thin => true}
            Diff:
            @@ -3,7 +3,7 @@
             :device_type => "disk",
             :filename => "2d41b00f-d594-47dd-9148-931731ddf8ff",
             :format => "cow",
            -:location => "0",
            +:location => "0:0",
             :mode => "persistent",
             :present => true,
             :size => 46137344,

          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:763:in `assert_specific_template'
          # ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:28:in `block (3 levels) in <main>'

Finished in 6.64 seconds (files took 2.95 seconds to load)
5 examples, 1 failure

Failed examples:

rspec ./spec/models/manageiq/providers/redhat/infra_manager/refresher/refresher_4_async_graph_spec.rb:12 # ManageIQ::Providers::Redhat::InfraManager::Refresher will perform a full refresh on v4.1

Thanks, I forgot to update this provider after the change 😔

No problem!  I'm so happy it's not related to the code loading changes I'm testing for rails 7. 🤣

Backported to radjabov in commit 20c21f633791d5d4c355517f35b4639ddb583517.
commit 20c21f633791d5d4c355517f35b4639ddb583517
Author: Adam Grare <adam@grare.com>
Date:   Tue Mar 19 15:10:20 2024 -0400

    Merge pull request #46 from jrafanie/add_controller_prefix_to_disk_location_column

    Add controller prefix to disk location column

    (cherry picked from commit 1bb076a3d966afe627e46e5d458cb1df5fbf9110)

authors: Fryguy jrafanie


text:
Error after deleting intermediate snapshot

(Euwe) After deleting an intermediate snapshot of multiple snapshots, clicking on 'Snapshots' within the VM details page has no effect. In production.log the error is seen.
Steps to reproduce the issue:

Go to the details page of a VMware VM
Click on 'Snapshots' (see screenshot below)
Add a snapshot
Wait for the completion of the snapshot (refresh details page and observe Snapshots count)
Add a second snapshot
Wait for the completion of the snapshot (refresh details page and observe Snapshots count)
Delete the first snapshot
Wait for the deletion of the first snapshot (refresh details page and observe Snapshots count)
Click on 'Snapshots' on the VM details page
You would expect the Snapshots details page to show but nothing happens and a fatal error is logged to production.log

After logging out and logging in again the snapshots management page is reachable again.
production.log
[----] I, [2017-01-17T16:09:07.479652 #24178:16202a4]  INFO -- : Started POST "/vm_infra/show/1000000000022?display=snapshot_info" for 127.0.0.1 at 2017-01-17 16:09:07 +0100
[----] I, [2017-01-17T16:09:07.523259 #24178:16202a4]  INFO -- : Processing by VmInfraController#show as JS
[----] I, [2017-01-17T16:09:07.523409 #24178:16202a4]  INFO -- :   Parameters: {"authenticity_token"=>"oF2W8IHE20Bk0azZOdWGCjbmpAjF/qmsZUpnRJxC/bpCv71RV8Y+iioXyzoIyjbynAIimbDceNr68IUwwsAxYw==", "display"=>"snapshot_info", "id"=>"1000000000022"}
[----] I, [2017-01-17T16:09:07.622176 #24178:16202a4]  INFO -- :   Rendered layouts/_flash_msg.html.haml (0.1ms)
[----] I, [2017-01-17T16:09:07.633864 #24178:16202a4]  INFO -- :   Rendered vm_common/_snapshots_desc.html.haml (6.5ms)
[----] I, [2017-01-17T16:09:07.634002 #24178:16202a4]  INFO -- :   Rendered vm_common/_config.html.haml (16.6ms)
[----] F, [2017-01-17T16:09:07.634234 #24178:16202a4] FATAL -- : Error caught: [ActionView::Template::Error] Couldn't find Snapshot with 'id'=1000000000022
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/activerecord-5.0.0.1/lib/active_record/core.rb:173:in `find'
/var/www/miq/vmdb/app/views/vm_common/_snapshots_desc.html.haml:5:in `_app_views_vm_common__snapshots_desc_html_haml___319794043838976554_233122420'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/actionview-5.0.0.1/lib/action_view/template.rb:158:in `block in render'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/activesupport-5.0.0.1/lib/active_support/notifications.rb:166:in `instrument'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/actionview-5.0.0.1/lib/action_view/template.rb:348:in `instrument'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/actionview-5.0.0.1/lib/action_view/template.rb:156:in `render'

Thanks for the bug report @kruge002 !
I was able to reproduce this and I suspect it is a UI issue.
This is the error on upstream/master:
[----] F, [2017-01-19T11:27:07.810357 #32231:2ad497fc0ae4] FATAL -- : Error caught: [ActionView::Template::Error] Couldn't find Snapshot with 'id'=2
/var/lib/gems/2.3.0/gems/activerecord-5.0.1/lib/active_record/core.rb:173:in `find'
/home/agrare/.bundle/ruby/2.3.0/manageiq-ui-classic-90608b7beb94/app/views/vm_common/_snapshots_desc.html.haml:5:in `__home_agrare__bundle_ruby_______manageiq_ui_classic______b_beb___app_views_vm_common__snapsho
/var/lib/gems/2.3.0/gems/actionview-5.0.1/lib/action_view/template.rb:159:in `block in render'

If we look at https://github.com/ManageIQ/manageiq-ui-classic/blob/master/app/views/vm_common/_snapshots_desc.html.haml#L5
It is trying to find the previous snapshot that you had selected: selected_id = Snapshot.find(session[:snap_selected]) but the snapshot that you had selected is now removed from the db.
Assigning to the UI team.

This issue was moved to ManageIQ/manageiq-ui-classic#209

@Fryguy @chessbyte please close this issue as I've copied it over to the ui-classic repo.  Thx, Dan

authors: agrare dclarizio kruge002

repo: ManageIQ/manageiq


text:
Confusing title in form for adding a new user

In form for adding a new user are required, besides other things, credentials titled as Name and User ID.

Confusing to me is, that User ID is value that is used for login, but in login form is title Username instead of User ID.

Also in Users table, there is Userid as title instead of User ID. I think that should be changed too.

I'd suggest to change string Name to Full name and User ID to Username in all views, but then I guess it would be also necessary to rename variables that are working with these data, which would probably be larger change.
I could start working on this, if you think, this should be changed.
@dclarizio @martinpovolny ?

@epwinchell @mfeifer Would appreciate your comments.

@romanblanco @dclarizio @martinpovolny @mfeifer  Sounds like a great idea to me. We should be consistent.

Definitely agree.

@romanblanco We can proceed on this, but I don't think we need to change the variables or DB fields associated with the user fields.  Probably just need to add dictionary entries, change the views and change any messages that mention these fields.

Verified and fix is available in both upstream and downstream.
Upstream -  master.20150518114920_83a5813

authors: dclarizio epwinchell mfeifer rananda romanblanco


text:
Split the show partial for performance

Separate the partial for the performance showtype from show
Links [Optional]
https://www.pivotaltracker.com/n/projects/1613907

@miq-bot add_label wip, ui, refactoring

Closing - opened a new PR on the ui classic repo. https://github.com/ManageIQ/manageiq-ui-classic/pull/12


text:
Patternfly styling cleanup 6

restored missing ie8 and ie9 classes in login and header - lost during HAML conversion
consolidated images

Issue: #1574

@dclarizio Please review


text:
Convert Vmdb::PermissionsStore to a blacklist

It's uncommon to prevent features, so the permissions store works better as a blacklist.  Otherwise, we are forced to add new items to the whitelist everytime we add things, even when most of the time we actually want them.
Other repos should not need to change except that I will need to change our production whitelist to a blacklist after this is merged.
@gtanzillo Please review.
cc @h-kataria @martinpovolny @agrare

Looks like a sporadic failure

Looks good to me.

This causes CI failure in ui-classic:
ApplicationHelper#role_allows? permission store consults the permission store
     Failure/Error: expect(Menu::DefaultMenu.services_menu_section.visible?).to be_truthy

       expected: truthy value
            got: false
     # ./spec/helpers/application_helper_spec.rb:62:in `block (5 levels) in <top (required)>'
     # ./spec/helpers/application_helper_spec.rb:50:in `block (4 levels) in <top (required)>'

@martinpovolny @himdel Gah! I said to myself "you know, I should run the UI tests before this gets merged.  If I had my bot-driven test system in place, it wouldn't have been a thought...I would have just done it. 😠

Even better, if one the Ruby tests from UI ran on each core PR ;-) (just 15 minutes of execution)

Ivanchuk backport details:
$ git log -1
commit 35c69a6a65529345191349f64662d0482de29e08
Author: Harpreet Kataria <hkataria@redhat.com>
Date:   Wed Jul 24 19:49:47 2019 -0400

    Merge pull request #19053 from Fryguy/blacklist_permissions_store

    Convert Vmdb::PermissionsStore to a blacklist

    (cherry picked from commit 7146738a0ae43b586b883480d42d5ff2c39dd96c)

authors: Fryguy agrare martinpovolny mzazrivec simaishi


text:
Document unique_within_region

Additionally this allows for grep of unique_within_region which is
otherwise Rails magic.

Jansa backport details:
$ git log -1
commit 27245f7bb39cb14ab991fbc065ef8d822a9cdd78
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Fri Apr 17 16:11:32 2020 -0400

    Merge pull request #20082 from Fryguy/document_unique_within_region

    Document unique_within_region

    (cherry picked from commit 444689d7be6e694fdf9f58f4af2a7927d494ead7)

authors: Fryguy simaishi


text:
Cleanup constantize of worker_class_names

Now that we only pull worker class names from the seeded database this seems like it shouldn't be an issue anymore but would like @jrafanie's opinion

Kicking travis now that the issue with xenial / ca certs is fixed


text:
Update custom matchers to modern API

Uses RSpec 3+ methods to remove deprecation warnings from custom matchers.
BeSameTimeAs matcher omitted here as it's been rewritten completely in #6098

@miq-bot add_label rspec3, technical debt

:+1: after fixing the conflicts

Fixed!

authors: Fryguy chrisarcand


text:
Use DRb's builtin caching mechanism

https://bugzilla.redhat.com/show_bug.cgi?id=1297097
Previously we have been using our own caching mechanism to
cache objects sent as references to the Automate Methods. We have
gotten DRb recycled object errors, since some of the objects which
were sent as references were not being cached.
DRb has a builtin caching mechanism based on TimerIdConv, which
we are starting to use in this PR.

@gmcculloug @Fryguy @jrafanie @matthewd
Please review

@Fryguy @gmcculloug
Changed to use 1.hour


text:
Upgrade puma so we can change the thread count used by rails server.

We run puma through rails server with options here
Note, Rails::Server and Rack::Server don't expose all web server options.
As of puma 3.0.0+, puma specific options can be put in config/puma.rb, see here
For each rack request, Rails' query cache middleware reserves a database connection
for the current thread here.
Puma spins up a thread for each request.
Therefore, we should have a database.yml pool greater than or equal to the puma
thread count or we risk a ActiveRecord::ConnectionTimeoutError waiting on a
connection from the connection pool.

@matthewd @Fryguy Please review.


text:
EdgeDirection::unit_vector is Y flipped?

Describe the bug
I'm using unit_vector to rotate objects in the hex. But it seams that Y component of this vector is always flipped.
To Reproduce
Here is a simple test, that calculates direction manually vs unit_vector:
let layout = HexLayout::default();
for direction in EdgeDirection::ALL_DIRECTIONS {
    let h0 = hex(0, 0);
    let h1 = h0.neighbor(direction);

    let h0pos = layout.hex_to_world_pos(h0);
    let h1pos = layout.hex_to_world_pos(h1);

    let look_to_test = (h1pos - h0pos).normalize();
    let look_to = direction.unit_vector(layout.orientation);

    println!("{look_to_test} vs {look_to}");
}

And here are results:
[0.8660254,   -0.49999997] vs [0.8660254,          0.5]
[0,           -0.99999994] vs [-0.00000004371139,  1]
[-0.8660254,  -0.49999997] vs [-0.8660254,         0.50000006]
[-0.8660254,   0.49999997] vs [-0.8660253,        -0.5000002]
[0,            0.99999994] vs [0.000000011924881, -1]
[0.8660254,    0.49999997] vs [0.86602527,        -0.5000002]

As you can see Y component is always flipped, while X is always the same (excluding rounding errors)
Expected behavior
unit_vector should return a direction to a neighbor hex.
Screenshots Or Code snippet
Provided above.

Nice catch, I'll write some tests to reproduce this behaviour and propose a fix asap

Okay so this was not a really bug but due to HexLayout having its Y axis inverted  by default

Okay so this was not a really bug but due to HexLayout having its Y axis inverted by default

But what does it represent than? Souldn't hex_to_world_pos also have Y flipped?

hex_to_world_pos is a method of HexLayout, so it had the inverted axis. The PR I opened changes this behaviour to have the default layout uninverted, matching methods like angle and unit vector computations outside of the layout.
You may review #187

unit_vector is not in world space. It doesn't know about:

The size of the hexagons
The axis scales
The world origin
etc

Therefore to be applied in world space transformations are needed. HexLayout could provide such transformations if you want to avoid doing the normalized world space operations

authors: ManevilleF MatrixDev

repo: ManevilleF/hexx


text:
Added public location to config

This is for some other stuff which I am doing on your plugin Please accept.

Added it in latest Commit https://github.com/MangoRageBot/MangoBot/commit/d94b2f7e3cfd290faa06948c2bd63d123da6833d

repo: MangoRageBot/MangoBot


text:
The "run" section should be owned by containers, not each animation.

There are two very separate concepts in "run" that we're conflating.
One is a record attached to each animation individually, saying things like "how long it's going to go on for".  Another is data attached to the entire project about things like the thread structure of the project itself - like the upcoming "run_on_main_thread" parameter coming in #355.
In the existing code, container animations usually overwrite most of their children's "run" sections.  That's a code smell - getting people to "fill out a form" and then throwing most of it away.  :-D
The top-level "run" section should stay basically unchanged.  However, run properties for children should be managed by their containers and not by individual animations.

Not true... sequence allows children to control fps, runtime, and others...
On Aug 11, 2017 5:18 AM, "Tom Swirly" notifications@github.com wrote:

There are two very separate concepts in "run" that we're conflating.
One is a record attached to each animation individually, saying things
like "how long it's going to go on for". Another is data attached to the
entire project about things like the thread structure of the project
itself - like the upcoming "run_on_main_thread" parameter coming in #355
https://github.com/ManiacalLabs/BiblioPixel/issues/355.
In the existing code, container animations usually overwrite most of their
children's "run" sections. That's a code smell - getting people to "fill
out a form" and then throwing most of it away. :-D
The top-level "run" section should stay basically unchanged. However, run
properties for children should be managed by their containers and not
by individual animations.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/356, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA6a6nXxEimkfCOoKtmYNHcULL0bQCr-ks5sXBxegaJpZM4O0a3R
.

authors: adammhaile rec

repo: ManiacalLabs/BiblioPixel


text:
Documentation Website Has Broken Links: I Can't Submit Pull Requests!

On each page of Docs.Manim.Community there is a Pencil icon if editing needs be for that page.
But now if I click the Pencil for any page it gives a 404!
For example:
If I go on this link:
https://docs.manim.community/en/stable/reference/manim.mobject.geometry.arc.Circle.html
And click the Pencil on the top-right I get a 404!
Fix it!

Thanks for letting us know, I wasn't aware our documentation theme has added an edit button feature.
The problem is: the way this is currently implemented does not work correctly with documentation pages generated from docstrings via autodoc: In the example you gave above, https://docs.manim.community/en/stable/reference/manim.mobject.geometry.arc.Circle.html tries to link to (after setting up things correctly) https://github.com/ManimCommunity/manim/edit/main/docs/source/reference/manim.mobject.geometry.arc.Circle.rst, so it basically is looking for the corresponding document in our docs/source directory.
However, it cannot be found there as this page is autogenerated from the docstring of the Circle class in https://github.com/ManimCommunity/manim/blob/44f78f1dfdd7498542869fc06bb39619f2b2d57b/manim/mobject/geometry/arc.py#L467-L490
We'll have to disable the feature for now.

Huh? But what do we do if we have edits to make?
Many pages have properties left unexplained/blank.
Important properties not even mentioned in the Doc pages.
Text(...) has attributes not explained in the Doc.
Also, Circle(...) lacks the important attribute stroke_width which works, is a crucial parametre but never mentioned it is possible to customise.

Huh? But what do we do if we have edits to make?

You can still edit the documentation of classes and methods, you just need to navigate to the corresponding page manually on GitHub. The redirect from the documentation page to GitHub does not work; editing the docstrings works just normally.

Text(...) has attributes not explained in the Doc. Also, Circle(...) lacks the important attribute stroke_width which works, is a crucial parametre but never mentioned it is possible to customise.

stroke_width should be documented as an argument of VMobject in https://docs.manim.community/en/stable/reference/manim.mobject.types.vectorized_mobject.VMobject.html#manim.mobject.types.vectorized_mobject.VMobject. With how the documentation is setup currently, you often have to look for arguments in the base classes of the class you are interested in. (Not saying I particularly like this system, but that is how it currently is.)

O.K.

authors: AnonymoZ behackl

repo: ManimCommunity/manim


text:
new feature: animation slideshow

Idea for a new feature
Motivation
Currently manim animations are mostly being used to create videos in which mathematical concepts are being explained. However, many people might benefit from an option where the manim user can navigate through the animations with the left and right arrows. Possible use cases for this are presentations, lectures, ...
This way it is easier to pause and explain some concept and then proceed with the next animation. Additionally, this should enable the presenter to go back and reference an old slide /frame of an animation.
Current features in manim

each animation is rendered as a separate video
'save-last-frame' option can be enabled

What needs to be done

create outline of presentation from video animations and corresponding frames (which file should be played/shown when?)
create a simple GUI (or maybe even only a key logger) which recognizes when the right and left arrow have been clicked and plays the correct video animation, at the end of the video the last frame is being shown

This is a great idea and something I would love to see in manim. @yoshiask even has a PPT-exporter functionality already!
My personal problem is that I don't use PPT, so I was never able to use @yoshiask add-on. So I had to make my own. My version works by making manim render the .mp4 video of each individual animation, as well as a .png of the first frame of each animation. Then with a single .html document I can load all of that into a browser. Using a bit of JS/CSS I can use the arrow keys to present the animations. The png of the first frame of each animation is used as a thumbnail for each "slide" of the presentation. This is just a description of how mine works, but I don't mean to say this is how it should work!
I have a working version of this on my local setup. It's not in a state that can be PR'd right now, and it was developed with an old version of manim so I don't think it will work correctly anymore. The main problem is that the partial movie files now have different names (previously they were ordered but now they have their has in their names) Cc @ManimCommunity/scene-caching.
In any case, let's discuss how this would look like and let's implement it after the release of v0.1.

Hi!
This is typically something that could be achieve in the livestreaming feature. see #441, but it's not the first purpose.
Otherwise, I think that putting the partial movie files in order as @leotrs did is the probably the best idea. The best is probably to directly use a stream to do that, and that's why I mentionned livestreaming.
If you have any suggestion, feel free :D

As useful as a feature like this would be, I don't really see why it has to be specific to Manim. Also, this could be implemented entirely as an add-on, so if users don't want it they don't have to download it.

You can also make use of the slideshow creation capabilities of Jupyter notebooks when making use of an extension like https://github.com/krassowski/jupyter-manim for a very straightforward way of including/showing videos. (Not sure whether you can manage to show the videos fullscreen then, though -- but it might be worth investigating.)
(jupyter-manim does not support the community version of manim. yet. :-))

Also, this could be implemented entirely as an add-on

Indeed many things could be...
...but here is what manim itself should be able to do at a minimum:

Create an initial image
create one video file per animation
save the last frame of each animation
Copy all images and videos into one folder with a naming system that makes sense (like: numbered)

From that point on this data can be worked into different presentation softwares. We could talk about an in-browser html-based presentation or compiling a ppt or an applewhatever file. This is the point where add-ons might come in.
Bonus:
Point 2 but where it is not one video per animation, but where the breaks happen at points that the user specifies in the scene - i.e. allow the user to bundle a few animations into one transition.

As useful as a feature like this would be, I don't really see why it has to be specific to Manim. Also, this could be implemented entirely as an add-on, so if users don't want it they don't have to download it.

Yes. This is another reason why I haven't PR'd anything.

As useful as a feature like this would be, I don't really see why it has to be specific to Manim. Also, this could be implemented entirely as an add-on, so if users don't want it they don't have to download it.

I mean you are probably right. It would be nice to have access to such a feature one way or the other though. Since it is a useful feature, it should then be transparent for the user, where these add-ons can be found. Especially if they are of interest for many people. Maybe you could include a list of useful add-ons in the sphinx documentation of manim?

I believe an MVP for this is fairly easy to implement. I'm just waiting to close #183 before moving on to this one. If anyone else cares, go ahead!

I have a toy implementation that seems pretty close to the feature that has been requested here, see https://gist.github.com/behackl/c92b467aec723cc6f06bd4dd2527c009 -- after adding some sort of (python) webserver as an optional dependency, that approach could probably be implemented as a CLI subcommand (manim slideshow file.py SomeScene...).
(Personally, I would find that useful because I'd then use the html-slideshow as a browser source in OBS, which I find a lot more comfortable than including a video.)

Closing this since there is a plugin, https://github.com/galatolofederico/manim-presentation, which does more or less what is discussed here.

authors: behackl cobordism huguesdevimeux leotrs mathmerizing yoshiask


text:
Keep Some Mobjects in Fixed Place in MovingCameraScene

There is a add_fixed_in_frame_mobjects method to keep mobjects in a fixed place in ThreeDScene class. However, it is not available in the MovingCameraScene class.
How can I keep an object fixed in the frame while the camera position moves around? Just like the position:fixed property in CSS while we scroll up and down the page.
Thanks.

Hi @baljeetrathi! Thanks for asking this. Unfortunately I don't have an answer. In fact, it may very well be impossible. For more discussion, I suggest you go to our discord server and use one of the #help chanells. I'm sure more people there will be able to help you.

MovingCameraScene doesn't support this, but ThreeDScene does and can be used. A workaround would be to create a group with the camera frame and whichever mobjects should be fixed, and then move the group. Not sure whether the workaround is required though, just use ThreeDScene.
Closing.

authors: baljeetrathi behackl leotrs


text:
Mention poetry installation via brew.

I recently discovered that you can install poetry with the Homebrew package manager. This is not mentioned in the Poetry documentation, so I'm planning on adding this note there as well. Meanwhile, I though this should also be here.

List of Changes

Added a note in the documentation about Poetry being installable via the Homebrew Package manager.

Motivation

We point out that alternative methods of installing poetry exist, and though this is also one of them, it isn't mentioned in the Poetry documentation. I'm planning on taking a PR there (later), but until then, this will hopefully suffice.
Explanation for Changes
Mentions an unmentioned method of installation.
Testing Status
Looks fine.
Acknowledgement

[x] I have read the Contributing Guidelines

Right. I don't see how that's a problem though, considering that if you
install poetry via brew, it will install it only after installing the
latest version of python.
If you have Python 3.8 and try to install poetry, brew will install Python
3.9 automatically.
On Sun, 1 Nov 2020, 21:07 Naveen M K, notifications@github.com wrote:

@naveen521kk commented on this pull request.
In docs/source/installation/for_dev.rst
https://github.com/ManimCommunity/manim/pull/662#discussion_r515636560:

@@ -21,7 +21,7 @@ If you are a Windows developer and want to use PowerShell, you can use the below

(Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python

-.. note:: Poetry can be installed by other ways also, such as with pip. See <https://python-poetry.org/docs/#alternative-installation-methods-not-recommended>.
+.. note:: Poetry can be installed by other ways also, such as with pip. See <https://python-poetry.org/docs/#alternative-installation-methods-not-recommended>. If you are using MacOS with the Homebrew package manager, you can also install poetry with brew install poetry.
Hmm. The issue says you can use things used with brew only. Say you
install python 3.9 with brew and also peotry, then poetry will always find
python 3.9 and can't use python installed using other means.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManimCommunity/manim/pull/662#discussion_r515636560,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH5H6JC2EVNWQ6GADRSUBCDSNV6FNANCNFSM4TGO5HEA
.


text:
Open source the release and changelog feature

What
In the current Manomano internal project, homer offers the option of publishing and displaying a project's change log using the following commands :

/homer changelog Generate changelogs for any Gitlab project using release tags.
/homer release Create a Gitlab release.
/homer release cancel Cancel a Gitlab release.
/homer release end End a Gitlab release.

These functionalities should be reviewed and modified to make them available in the open-source project.
How
In order to add a releasable project, an internal configuration file must be modified. This behaviour needs to be reviewed to simplify the process and avoid the need to redeploy homer each time.
Firstly, we should externalise this configuration, and write documentation about it.
Then we could add a command like /homer release enable to register a new releaseable project.
The current configuration is as follows:
{
    notificationChannelIds: [
      IT_DEPLOY_CHANNEL_ID,
      FT_SELLER_CHANNEL_ID,
    ],
    projectId: 1,
    releaseChannelId: FT_SELLER_CHANNEL_ID,
    releaseManager: defaultReleaseManager,
    releaseTagManager: semanticReleaseTagManager,
  },

projectId : Gitlab project ID
notificationChannelIds : ID of the Slack channels that receive notifications about the release
releaseChannelId : ID of the slack channel where the release of the project is enabled
releaseManager : change depending on the type of the project (library, micro-service, frontend ..)
releaseTagManager : defines the tag naming (semantic, stable date ...)
The modal could be like this :

I opened this MR before someone is working on this topic

This one can be closed

repo: ManoManoTech/homer


text:
Excessive nesting for declaring events in the code

Vanilla Blaze:
Template.my.events
  'click #id': ->

VS ViewModel:
Template.my.viewmodel
  events:
    'click #id': ->

I want to suggest:
Template.my.viewmodel.events
  'click #id': ->

PS I know about binding events by function name, but ...

You can still use
Template.my.events
  'click #id': ->

with ViewModel

But I want to use "this" of ViewModel inside event handler.
Template.my.events
  'click #id': (e, t) ->
    t.viewmodel.myValue()

VS
Template.my.viewmodel.events
  'click #id': ->
    @myValue()

There is no way you'll convince me that
Template.example.viewmodel
  myValue: ''

Template.example.viewmodel.events
  'click #id': ->
    @myValue()

is somehow cleaner/easier/better than:
Template.example.viewmodel
  myValue: ''
  events:
    'click #id': ->
      @myValue()

OK. I may use:
Template.example.viewmodelEvents =
  'click #id': ->
    @myValue()

Template.example.viewmodel
  myValue: ''
  events: Template.example.viewmodelEvents

authors: ManuelDeLeon comerc

repo: ManuelDeLeon/viewmodel