text:
Packet setup is unstable

Description
During the packet cluster setup we need to reboot servers to enable SR-IOV on them. Sometimes for some reason server fails to start after the reboot.

Currently it is not so clear what is the reason, so I am communicating with the packet support team.

Ticket created: https://support.equinixmetal.com/hc/en-us/requests/12702

We are aware of an issue that has affected UEFI systems (not BIOS) systems with Ubuntu and GRUB. There's a writeup at https://gist.github.com/vielmetti/dafb5128ef7535c218f6d963c5bc624e - I don't think this affects you, but worth a look.

The issue is still active, reopened the ticket: https://support.equinixmetal.com/hc/en-us/requests/14125.

@vielmetti Could you help us out with getting our ticket reopened here?

Equinix Metal has identified a hardware issue (BIOS configuration) that would explain the problem as presented, and we've corrected that problem on one machine. The next round of work is verifying this configuration option on the rest of the fleet. Thanks @Bolodya1997 for the detailed descriptions which helped us track this down.

Several servers in the rest of the fleet have had BIOS configuration changes, which should correct the problems as described. Please report any issues that you see!

Looks like it is no more reproducible after the BIOS fix, closing this issue.

authors: Bolodya1997 edwarnicke vielmetti


text:
Upgrade to vppagent 3.1.0

Overview
It would be good to have 3.1.0 to be used:
https://github.com/ligato/vpp-agent/blob/v3.1.0/CHANGELOG.md#v3.1.0

Fixed by https://github.com/networkservicemesh/networkservicemesh/pull/2134

source: gharchive/issue

authors: denis-tingajkin haiodo

repo: networkservicemesh/networkservicemesh

license_type: permissive

license_source: bigquery


text:
spire namespace missing on a clean helm deploy

Expected Behavior

Installing NSM with helm3 from networkservicemesh/deployments/helm/nsm should render a working NSM system.
Current Behavior

The installation fails with error, that the namespace spire does not exist.
Failure Information (for bugs)

Steps to Reproduce
with a system that previously did not run NSM, or as I had an older version of NSM which I removed.
system info:
[root@kube-master ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.8", GitCommit:"35dc4cdc26cfcb6614059c4c6e836e5f0dc61dee", GitTreeState:"clean", BuildDate:"2020-06-26T03:43:27Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.8", GitCommit:"35dc4cdc26cfcb6614059c4c6e836e5f0dc61dee", GitTreeState:"clean", BuildDate:"2020-06-26T03:36:03Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
[root@kube-master ~]# helm version
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}
If you have nsm installed remove it.
check if you have a spire namespace lingering, if so remove it.
[root@kube-master ~]# kubectl get namespaces
NAME              STATUS   AGE
default           Active   314d
kube-node-lease   Active   314d
kube-public       Active   314d
kube-system       Active   314d
spire             Active   3d20h
[root@kube-master ~]# kubectl delete namespace spire
namespace "spire" deleted
check git commit id:
cd networkservicemesh/deployments/helm
git log
commit 7bda1b173bd43d678745416c69e7197876aff332 (HEAD -> master, origin/master, origin/HEAD)
Author: xzfc xzfc@users.noreply.github.com
Date:   Mon Sep 21 06:10:46 2020 +0000
Put limits on containers created by admission-webhook (#2188)

Signed-off-by: Albert Safin <albert.safin@xored.com>

Then install:
[root@kube-master helm]# helm install nsm nsm
Error: namespaces "spire" not found
[root@kube-master helm]# helm ls
NAME	NAMESPACE	REVISION	UPDATED                                 	STATUS	CHART    	APP VERSION
nsm 	default  	1       	2020-09-25 11:52:26.112214522 +0200 CEST	failed	nsm-0.2.0	0.2.0
helm delete nsm
Ok, so add namespace spire.
[root@kube-master helm]# kubectl create namespace spire
namespace/spire created
root@kube-master helm]# helm install nsm nsm
NAME: nsm
LAST DEPLOYED: Fri Sep 25 11:54:32 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
[root@kube-master helm]# helm ls
NAME	NAMESPACE	REVISION	UPDATED                                 	STATUS  	CHART    	APP VERSION
nsm 	default  	1       	2020-09-25 11:54:32.957777121 +0200 CEST	deployed	nsm-0.2.0	0.2.0
Works fine now, after manually creating the spire namespace

@haiodo @denis-tingajkin Could someone get a look at this?

authors: One-ders edwarnicke


text:
Own dataset not working

TO DO:  # enable this optional step to upload and colab calibrate your own images  # and prepare dataset for svox2 to extract voxels via svox2 # . What do I need to upload here? Dataset with rgb images and poses OR a video?

just folder with numbered rgb images and run the script .Follow guide in svox2 repo

repo: neurall/PlenoxelsColab

license_source: github-api


text:
tests issue

I've slightly changed how variables and ops are named in model.py. Then test_training in  tests/test.py started to fail, complaining that a particular name was not in the checkpoint. However, when I simply changed the database name, the tests started to pass, suggesting that in the first case something was being loaded from previously run tests.

I suspect this is because of local caching. The test should delete the
local cache, which it currently doesn't, in addition to dropping the test
database, which it currently does. I guess we should have real test setup
and teardown.
On Tue, Mar 21, 2017 at 5:28 AM Jonas Kubilius notifications@github.com
wrote:

I've slightly changed how variables and ops are named in model.py. Then
test_training in tests/test.py started to fail, complaining that a
particular name was not in the checkpoint. However, when I simply changed
the database name, the tests started to pass, suggesting that in the first
case something was being loaded from previously run tests.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/neuroailab/tfutils/issues/59, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOHizLnRtGTylm3HbBTctZ1VWz5y0Y2ks5rn8J4gaJpZM4MjueK
.

repo: neuroailab/tfutils

license: mit


text:
Write e2e test for pheno subcommand using example_synthetic

Given example_synthetic.json and example_synthetic.tsv, the contents of the generated .jsonld should match that in example_synthetic.jsonld.

[ ] update .json and .tsv for this example to pre-define the dataset and subject UUIDs (otherwise the ones randomly generated during the test won't match the IDs in the provided .jsonld)

@surchs thoughts on the UUID issue? My proposed approach is a little bit brute force but I'm not sure if we're currently planning to handle user-defined UUIDs.

The UUIDs are not meant to be persistent and shouldn't be used to address specific data because they are expected to change every time you make a new instance of the dataset. The main reason we have them now is so we don't have blank nodes in the graph (i.e. nodes with no identifier) because for those Stardog has to come up with random ids - and it doesn't always do so in a way that doesn't lead to id clashes.
So the short answer is: I don't think there is a point in writing a test to make sure that the output is an identical copy of the example file, including the UUIDs.

Makes sense. Closing this issue in that case!

authors: alyssadai surchs

repo: neurobagel/bagelbids

license: MIT


text:
checklist

This list is for checking by myself:

[ ] Check theorem and corollary and proofs
[ ] Consider another corollary for weighted & directed graph
[x] Are we still doing Node contributions?

After Monday:

[ ] exclude 3.4? due to growing variance.
[ ] add a real data where MGC is best?
[ ] should we add multivariate node attribute?
[ ] check figure 5 for 11
[ ] check proof of thm 2.5
[ ] check node contribution for SBM model

notes to discuss:

[  ] remove Ctilde row from fig 4
[ ] improve fig 5, same y axis
[ ] improve fig 10, see beyond 0.5, change 0.2 to 0.3, etc
[ ] discuss fig 13
[ ] a multivariate simulation (2D gaussian mixutre)

repo: neurodata/Multiscale-Network-Test


text:
Commenting Out Default Auth

This is pending a custom class write for authentication classes.

Closing in favor of #432

source: gharchive/pull-request

repo: neurodata/ndstore


text:
dncbm.visualization

Thank you for providing the code and the visualization module.
Can you add the code for the Canvas class. The visualization module in dncbm doesn't exist (from dncbm.visualization.canvas import Canvas) doesn't exist

Thanks for pointing this out, we have now uploaded the functions. Sorry for the inconvenience.

authors: ai-voyage sukrutrao

repo: neuroexplicit-saar/Discover-then-Name


text:
MNEFilter with fftconvolve

Simple change, just change np.convolve to scipy.fftconvolve to do the convolution on all channels at once. Reduces nm_bursts computation time by 14% in my benchmark.
Output is the same, save floating point error (identical up to the 13th or 14th decimal place).
Had this in the backburner waiting for the #329 merge, didn't want to add more non-settings changes to that PR.

Many thanks @toni-neurosc! Makes a lot of sense to add it, also since it's present now in the sharpwave analysis.

authors: timonmerk toni-neurosc


text:
[ENH] Support symmetric GCLDA topics with more than two subregions

Closes #491.

Changes proposed in this pull request:

Allow multiple symmetric pairs of subregions in GCLDA.

@tyarkoni no pressure to review this PR in detail if you don't have the time, but I'd like to know if the general idea is, well, bad.

I don't have time to review this in detail, unfortunately, but I don't see any principled problem with this, so long as the results look sane for reasonable values. Do they look sane?

Thanks! The four-region results in the example look reasonable, but I will try running a more realistic version soon:

One question- why are the paired regions' covariances estimated independently? For the "symmetric" option, wouldn't it make more sense for the regions to be symmetric not just in terms of centroid, but also in terms of skew and direction?

Yeah that looks fine to me.
Re: symmetric covariances, I don't remember the reasoning, but I'm guessing it was probably some combination of (a) the brain isn't actually completely symmetric, and (b) in a sense it's a nice sanity check, because if the covariances look pretty similar, despite being estimated separately, that's a good sign the model is behave reasonably. But I wouldn't have any objection to parameterizing that as an option too.

Thanks. I'll open an issue about a new option for symmetric covariances.

authors: tsalo tyarkoni

repo: neurostuff/NiMARE