gopikrsmscs/torch-issues huggingface dataset:
pytorch-android-lite use its own libfbjni.so, which is not compatible with any other version at all..
Labels: oncall: binaries, triaged, module: android

### 🐛 Describe the bug

Wanted to have react-native and pytorch lite together in one project.

Already wasted 2 full working days on that, only to find out the root problem (well, there are 2).

The first problem is that strange "0.0.3" version of fbjni, which NEVER existed (and should never). If you go to the fbjni page, you will also see, there was NEVER a release of 0.0.3. Yet, someone uploaded to maven and enough are referencing to it.

0.2.2 should be the version, where react-native >=0.65 and pytorch(lite) should work together, if pytorch lite didnt change the library itself and then break everything else, as you cannot say which .so it should use. Just "pickFirst (woow at android gradle for that)".

Just make a small demo pytorch android lite project and then change your implementation to that (in build.gradle) :

    implementation 'com.facebook.fbjni:fbjni:0.2.2' //(not java-only, really that one)
    implementation ('org.pytorch:pytorch_android_lite:1.12'){
        exclude module:'fbjni'
        exclude module:'fbjni-java-only'
        exclude module:'soloader'
        exclude module:'nativeloader'
    }
Also dont forget to say "which" .so it should pick
android {
     packagingOptions {
        pickFirst "**/*.so"
    }
}

Try to start your demo project now and it will just crash with that:
cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.planradar.demoML-IK4F5CYrCuaaR7Csu8YHzQ==/lib/arm64/libpytorch_jni_lite.so"

Then just REMOVE the exclude parts and also remove the import of fbjni0.2.2. Then build your app again and it works again..

Basically your dependency says, it needs fbjni:0.2.2 (which is true), but you somehow change the library itself, resulting in a bigger .so file.

The problem is, that when using react-native together, it always picks the "wrong" one. So the one with 170kb. React-native starts fine, but pytorch just crashes.

I replaced the .so file manually (apktool and signing) and then react-native and pytorch are starting fine.

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.23.1
Libc version: glibc-2.26

Python version: 3.7.5 (default, Feb 23 2021, 13:22:40)  [GCC 8.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-74-generic-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[conda] Could not collect



PS.: I tested with pytorch android lite 1.11 and 1.12

cc @ezyang @seemethere @malfet
[CI] Detect when tests are no longer running from CI
Labels: module: ci, triaged

### 🐛 Describe the bug

A few days ago (as of 5/25), the mac CI tests stopped running as a result of a yml change that broke GHA parsing (see https://github.com/pytorch/pytorch/pull/78000). 

The scary part is that we only noticed it days later, and there was no automatic mechanism warning us that the test was missing. We should have such a mechanism.

How we can detect when this happens next time:
1. We could warn when the number of test cases run for a commit has dropped significantly even when there are no pending jobs 
2. We could warn when the number of workflow jobs run for a commit has dropped from the previous workflow run

How should we warn?
- Send an email to OSS CI oncall
- Auto create an issue and tag module: ci and high-priority
- Configure an alert that looks different from our other alerts

### Versions

CI

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Floating point exception in _conv_depthwise2d
Labels: triaged, module: edge cases

### 🐛 Describe the bug

Floating point exception in `_conv_depthwise2d`.

### Example to reproduce

```python
import torch

torch.cuda.init()

gpu_dev = torch.device('cuda')

tensor_0 = torch.full((4, 1, 3, 3,), 1, dtype=torch.float64, requires_grad=False, device=gpu_dev)
tensor_1 = torch.full((4, 1, 3, 3,), 0.5, dtype=torch.float64, requires_grad=False, device=gpu_dev)
intarrayref_2 = [1, 1]
tensor_3 = torch.full((4,), 1, dtype=torch.float64, requires_grad=False, device=gpu_dev)
intarrayref_4 = [0, 0]
intarrayref_5 = [0, 0]
intarrayref_6 = [0, 0]
torch._C._nn._conv_depthwise2d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5, intarrayref_6)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

PyTorch version: 1.11.0a0+git1efeb37
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 4.3.21300-5bbc51d8

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-14-amd64-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: Lexa XT [Radeon PRO WX 3100]
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 40321.30
MIOpen runtime version: 2.12.0
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0a0+gitfdec0bf
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.11.0a0+gitcb6fe03          pypi_0    pypi
Any plan to add Noam scheduling?
Labels: triaged, module: LrScheduler

### 🚀 The feature, motivation and pitch

I found Noam scheduling(from "Attention is all you need" paper) important for training transformers.
But it's not included in torch.
Do you have plan to add it or want others to add it?

### Alternatives

_No response_

### Additional context

_No response_
`max_unpool2d` is not deterministic
Labels: module: numerical-stability, module: nn, triaged, module: determinism, module: pooling

### 🐛 Describe the bug

`max_unpool2d` is not deterministic

```python
import torch

def test():
    kernel_size = 2
    stride = 2
    unpool = torch.nn.MaxUnpool2d(kernel_size, stride=stride, )

    input0_tensor = torch.rand([1, 1, 2, 2], dtype=torch.float32)
    input1_tensor = torch.randint(-2, 8, [1, 1, 2, 2], dtype=torch.int64)

    input0 = input0_tensor.clone()
    input1 = input1_tensor.clone()
    try:
        res1 = unpool(input0, input1)
    except Exception:
        res1 = torch.tensor(0)

    input0 = input0_tensor.clone()
    input1 = input1_tensor.clone()
    try:
        res2 = unpool(input0, input1)
    except Exception:
        res2 = torch.tensor(0)

    if torch.allclose(res1, res2) == False:
        print(input0_tensor)
        print(input1_tensor)
        print(res1)
        print(res2)
        return True
    else:
        return False

for _ in range(1000):
    if test():
        break
# tensor([[[[0.8725, 0.3154],
#           [0.7132, 0.8304]]]])
# tensor([[[[1, 6],
#           [1, 5]]]])
# tensor([[[[0.0000, 0.7132, 0.0000, 0.0000],
#           [0.0000, 0.8304, 0.3154, 0.0000],
#           [0.0000, 0.0000, 0.0000, 0.0000],
#           [0.0000, 0.0000, 0.0000, 0.0000]]]])
# tensor([[[[0.0000, 0.8725, 0.0000, 0.0000],
#           [0.0000, 0.8304, 0.3154, 0.0000],
#           [0.0000, 0.0000, 0.0000, 0.0000],
#           [0.0000, 0.0000, 0.0000, 0.0000]]]])
```

### Versions

pytorch: 1.11.0

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @kurtamohler
Performance with MPS on AMD GPUs are worse than CPU
Labels: module: performance, triaged, module: mps

### 🐛 Describe the bug

I tried running some experiments on the RX5300M 4GB GPU and everything seems to work correctly. The problem is that the performance are worse than the ones on the CPU of the same Mac.

To reproduce, just clone the tests in this repo `https://github.com/lucadiliello/pytorch-apple-silicon-benchmarks` and run either
```bash
python tests/transformers_sequence_classification.py --device mps --pre_trained_name bert-base-cased --mode inference --steps 100 --sequence_length 128 --batch_size 16
```
or
```bash
python tests/transformers_sequence_classification.py --device cpu --pre_trained_name bert-base-cased --mode inference --steps 100 --sequence_length 128 --batch_size 16
```

While the CPU took `143s`, with the MPS backend the test completed in `228s`. I'm sure the GPU was being because I constantly monitored the usage with `Activity Monitor`.

### Versions

PyTorch version: 1.13.0.dev20220524
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.3.1 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: Could not collect
Libc version: N/A

Python version: 3.8.12 (default, Oct 12 2021, 06:23:56)  [Clang 10.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.4
[pip3] torch==1.13.0.dev20220524
[pip3] torchaudio==0.12.0.dev20220524
[pip3] torchvision==0.13.0.dev20220524
[conda] numpy                     1.22.4                   pypi_0    pypi
[conda] torch                     1.13.0.dev20220524          pypi_0    pypi
[conda] torchaudio                0.12.0.dev20220524          pypi_0    pypi
[conda] torchvision               0.13.0.dev20220524          pypi_0    pypi

cc @VitalyFedyunin @ngimel
DISABLED test_complex_half_reference_testing_as_strided_scatter_cuda_complex32 (__main__.TestCommonCUDA)
Labels: module: rocm, triaged, skipped

Platforms:  rocm

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_complex_half_reference_testing_as_strided_scatter_cuda_complex32%2C%20TestCommonCUDA)).

cc @jeffdaily @sunway513 @jithunnair-amd @ROCmSupport @KyleCZH
test_to (__main__.TestTorch) fails with multiple gpus
Labels: module: multi-gpu, triaged, actionable

### 🐛 Describe the bug

The code below: 
https://github.com/pytorch/pytorch/blob/664bb4de490198f1d68b16b21407090daa995ba8/test/test_torch.py#L7645

sets the device as device 1 if multiple gpus are found. It compares against a tensor on device 0 and fails. This test is part of the single gpu tests, and should not be using distributed setup.

```
======================================================================
FAIL: test_to (__main__.TestTorch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_torch.py", line 7662, in test_to
    self._test_to_with_layout(torch.sparse_csr)
  File "test_torch.py", line 7654, in _test_to_with_layout
    self.assertEqual(b.device, a.to(cuda, non_blocking=non_blocking).device)
  File "/opt/conda/lib/python3.7/site-packages/torch/testing/_internal/common_utils.py", line 2258, in assertEqual
    msg=msg,
  File "/opt/conda/lib/python3.7/site-packages/torch/testing/_comparison.py", line 1086, in assert_equal
    raise error_metas[0].to_error()
AssertionError: Object comparison failed: device(type='cuda', index=1) != device(type='cuda', index=0)
```

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: 14.0.0 (https://github.com/RadeonOpenCompute/llvm-project roc-5.1.1 22114 5cba46feb6af367b1cafaa183ec42dbfb8207b14)
CMake version: version 3.22.1
Libc version: glibc-2.17

Python version: 3.7.13 (default, Mar 29 2022, 02:18:16)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-99-generic-x86_64-with-debian-bullseye-sid
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy==0.812
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.20.3
[pip3] torch==1.12.0a0+git0bf2bb0
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.20.3                   pypi_0    pypi
[conda] torch                     1.12.0a0+git0bf2bb0          pypi_0    pypi
Allow specifying pickle module for torch.package
Labels: enhancement, oncall: package/deploy, imported

### 🚀 The feature, motivation and pitch

I'm working on a service that is to receive files created with `torch.package` to instantiate `torch.nn.Module`s created by a different service. Some of the modules use, somewhere in their structure, lambda functions and other constructs that are not supported by `pickle`, but are supported by the `dill` package.

Seeing as how the `torch.save` and `torch.load` functions both support specifying a `pickle_module` to use, I was wondering if it was possible to support specifying it when instantiating `torch.package.PackageExporter` and `torch.package.PackageImporter`, so I could take advantage of the dependency bundling they provide?

### Alternatives

I can use `torch.save` and `torch.load` with `dill` as the `pickle_module`, though that in and out of itself doesn't bundle any dependencies needed to instantiate the module later on, and so I'd need both services to have the classes and methods, and updates on one side won't be reflected on the other.

I could also copy the source code of `torch.package`, make the necessary adjustments to it so that it uses `dill`, and use that code instead, but I'd have to make sure it is up to date with any changes made in this repository, and again will need this code to exist in both services.

### Additional context

_No response_
[chalf] reference_testing: low quality test for fast growing ops
Labels: triaged, module: complex, module: half

### 🐛 Describe the bug

In PR https://github.com/pytorch/pytorch/pull/77640: 
Since range of chalf is much less compared to cfloat, we get `inf`s easily (eg. with `pow`, `exp`), so we cast `cfloat` back to `chalf`.

However, this is might mask an actual issue as we don't control the percent of input that will be valid. The correct approach would be to sample input which are valid given the range of `chalf`.

One of the approach would be to add extra meta-data to OpInfo.

cc: @ngimel @mruberry @anjali411 

### Versions

master

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved
[Optimizer Overlap] Parameter group support
Labels: oncall: distributed, triaged, module: ddp

### 🚀 The feature, motivation and pitch

We should investigate and fix any missing gaps with parameter group support in DDP's support for overlapped optimizers. Currently, we do not have unittests for optimizer overlap with parameter groups. 

We probably will scope this to only specifying parameter groups at construction time and not support `add_param_group` API. The reason is that these functional optimizers are supposed to be mostly transparent to user; user does not directly construct or access them and they work through DDP communication hook internals.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
[Optimizer Overlap] Proper checkpointing support
Labels: oncall: distributed, triaged, module: ddp

### 🚀 The feature, motivation and pitch

Currently, optimizer overlap with DDP does not support saving / loading checkpoints. The optimizer is not readily accessed from DDP, and thus there is no way to save / load in the optimizer's `state_dict`. 

Even if we could access the optimizer from DDP, it is a functional optimizer and not a regular torch.optim.Optimizer, and thus the regular `state_dict` APIs cannot be called. 

One potential solution is to make these functional optimizer instances inherit from torch.optim.Optim so that `state_dict` and `load_state_dict` can be reused out of the box. We will override methods that are unsupported on the functional optimizer but supported by regular torch.optim.Optimizer (such as `add_param_group`) to ensure user doesn't attempt to use unsupported behavior with functional optimizers. 

This is a feature request from torchrec.


### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
[Optimizer Overlap] Custom optimizer registration
Labels: oncall: distributed, triaged, module: ddp

### 🚀 The feature, motivation and pitch

Currently, DDP optimizer overlap only supports a subset of commonly used torch.optim.Optimizers. However, torchrec has the use case of using their own custom implemented optimizers, so we should add support for a registry + API to add to this registry to allow users to register their own custom optimizers to be overlapped with DDP.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
`pack_sequence` crash
Labels: triaged, module: edge cases

### 🐛 Describe the bug

`pack_sequence` crash

```python
import torch
sequences_0 = torch.rand([1, 16, 86], dtype=torch.float32)
sequences_1 = torch.rand([1, 85, 0], dtype=torch.float16)
sequences_2 = torch.randint(0, 2, [2, 84, 85], dtype=torch.bool)
sequences_3 = torch.randint(-8, 2, [0, 4, 85], dtype=torch.int8)
sequences = [sequences_0,sequences_1,sequences_2,sequences_3,]
enforce_sorted = 0
torch.nn.utils.rnn.pack_sequence(sequences, enforce_sorted=enforce_sorted, )
# Segmentation fault (core dumped)
```

### Versions

pytorch: 1.11.0
`ctc_loss` will backward crash
Labels: module: autograd, triaged, module: edge cases

### 🐛 Describe the bug

`ctc_loss` will backward crash

First, it will succeed in the forward pass

```python
import torch

log_probs = torch.rand([50, 16, 20], dtype=torch.float32).requires_grad_()
targets = torch.randint(-2, 2, [16, 30], dtype=torch.int64)
input_lengths = torch.randint(-4, 1, [16], dtype=torch.int64)
target_lengths = torch.randint(-4, 4, [16], dtype=torch.int64)
blank = 0
reduction = "mean"
zero_infinity = False
res = torch.nn.functional.ctc_loss(log_probs, targets, input_lengths, target_lengths, blank=blank, reduction=reduction, zero_infinity=zero_infinity, )
# succeed
```

But it will crash when backwarding
```python
res.sum().backward()
# Segmentation fault (core dumped)
```

### Versions

pytorch: 1.11.0
Ubuntu: 20.04
Python: 3.9.5

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
`baddmm` triggers INTERNAL ASSERT FAILED when input requires grad
Labels: module: autograd, triaged, actionable

### 🐛 Describe the bug

`baddmm` triggers INTERNAL ASSERT FAILED when input requires grad

```python
import torch

input_tensor = torch.rand([10, 3, 5], dtype=torch.complex64)
batch1_tensor = torch.randint(-4, 2, [10, 3, 4], dtype=torch.int8)
batch2_tensor = torch.randint(-4, 1, [10, 4, 5], dtype=torch.int8)

input = input_tensor.clone()
batch1 = batch1_tensor.clone()
batch2 = batch2_tensor.clone()
res1 = torch.baddbmm(input, batch1, batch2, )
# Normal Pass

input = input_tensor.clone().requires_grad_()
batch1 = batch1_tensor.clone()
batch2 = batch2_tensor.clone()
res2 = torch.baddbmm(input, batch1, batch2, )
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch.
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
`matmul, mm` triggers INTERNAL ASSERT FAILED when input requires grad
Labels: module: autograd, triaged, actionable

### 🐛 Describe the bug

`matmul` triggers INTERNAL ASSERT FAILED when input requires grad

```python
import torch

input_tensor = torch.randint(-8, 2, [11, 0, 4], dtype=torch.int8)
other_tensor = torch.rand([4], dtype=torch.float32)

input = input_tensor.clone()
other = other_tensor.clone()
res1 = torch.matmul(input, other, )
# Normal Pass

input = input_tensor.clone()
other = other_tensor.clone().requires_grad_()
res2 = torch.matmul(input, other, )
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch. 
```

Plus, `mm` also has such issue

```python
import torch
input_tensor = torch.randint(0, 2, [0, 3], dtype=torch.uint8)
mat2_tensor = torch.rand([3, 2], dtype=torch.float32)

input = input_tensor.clone()
mat2 = mat2_tensor.clone()
res1 = torch.mm(input, mat2, )

input = input_tensor.clone()
mat2 = mat2_tensor.clone().requires_grad_()
res2 = torch.mm(input, mat2, )
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch. 
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Enhancements to AliasDB to handle in-place operations
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/OVERVIEW.md#handling-mutability
`The intention is that if you only mutate the graph through AliasDb, you don't have to think about mutability/aliasing at all in your pass. As we write more passes, the interface to AliasDb will get richer (one example is transforming an in-place operation to its pure equivalent if we can prove it's safe).`

Is the work called out here to enhance AliasDB currently planned or in-progress? I've hit a few issues around in-place container mutations (ex.` aten::_set_item`)  and they don't seem to be handled well in torchscript generally (ex. parseIR does not support read-back of ops that do not produce a value). Expanding AliasDB to provide more tools to understand/resolve these ops would be helpful.

As an example, this function in torch-tensorrt currently misses in-place container operations as dependencies of an input value. Adding a pass to remove these ops or providing access to the underlying graph in AliasDB to identify dependencies correctly would help resolve these issues.
https://github.com/pytorch/TensorRT/blob/e9e824c0ef0a4704826a390fe7d2ef90272a56b7/core/partitioning/partitioning.cpp#L60

### Alternatives

_No response_

### Additional context

_No response_
Segfault in _pad_packed_sequence
Labels: triaged, module: edge cases

### 🐛 Describe the bug


Function `torch._pad_packed_sequence` contains segmentation fault.

### Example to reproduce

```
import torch

data = torch.full([1, 1, 1, 1], -10000, dtype=torch.float16, requires_grad=False)
batch_sizes = torch.full([0], 978, dtype=torch.int64, requires_grad=False)
batch_first = True
padding_value = False
total_length = torch.full([], -9937, dtype=torch.int64, requires_grad=False)
torch._pad_packed_sequence(data, batch_sizes, batch_first, padding_value, total_length)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in _grid_sampler_2d_cpu_fallback
Labels: triaged, module: edge cases

### 🐛 Describe the bug


Function `torch._grid_sampler_2d_cpu_fallback` contains segmentation fault.

### Example to reproduce

```
import torch

input = torch.full([3, 3, 3, 2], 9490, dtype=torch.float32, requires_grad=False)
grid = torch.full([0, 3, 8, 2, 4, 1], -9545, dtype=torch.float32, requires_grad=False)
interpolation_mode = 8330
padding_mode = 5934
align_corners = False
torch._grid_sampler_2d_cpu_fallback(input, grid, interpolation_mode, padding_mode, align_corners)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in _embedding_bag_forward_only
Labels: triaged, module: edge cases

### 🐛 Describe the bug

Function `torch._embedding_bag_forward_only` contains segmentation fault.

### Example to reproduce

```
import torch

weight = torch.full([2, 2, 5, 3, 3], -8670, dtype=torch.float64, requires_grad=False)
indices = torch.full([3, 0, 1], -4468, dtype=torch.int32, requires_grad=False)
offsets = torch.full([7, 1, 0], -7226, dtype=torch.int64, requires_grad=False)
scale_grad_by_freq = True
mode = torch.full([], 6318, dtype=torch.int64, requires_grad=False)
sparse = False
per_sample_weights = torch.full([3], -8750, dtype=torch.int64, requires_grad=False)
include_last_offset = False
padding_idx = torch.full([], 6383, dtype=torch.int64, requires_grad=False)
torch._embedding_bag_forward_only(weight, indices, offsets, scale_grad_by_freq, mode,
                                  sparse, per_sample_weights, include_last_offset, padding_idx)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in torch._C._nn.thnn_conv2d
Labels: triaged, module: edge cases

### 🐛 Describe the bug

Function `torch._C._nn.thnn_conv2d` contains segmentation fault.

### Example to reproduce

```
import torch

tensor_0 = torch.full([3, 3, 3], -4398, dtype=torch.float64, requires_grad=False)
tensor_1 = torch.full([6, 7], -4532, dtype=torch.int32, requires_grad=False)
intarrayref_2 = -10000
tensor_3 = torch.full([3, 3, 3, 6, 7], -2321, dtype=torch.float16, requires_grad=False)
intarrayref_4 = -2807
intarrayref_5 = []
torch._C._nn.thnn_conv2d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).


### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in torch._C._nn.reflection_pad2d
Labels: triaged, module: edge cases

### 🐛 Describe the bug


Function `torch._C._nn.reflection_pad2d` contains segmentation fault.

### Example to reproduce

```
import torch

tensor_0 = torch.full([6, 5, 7], -8754, dtype=torch.int32, requires_grad=False)
intarrayref_1 = []
torch._C._nn.reflection_pad2d(tensor_0, intarrayref_1)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in max_unpool3d
Labels: triaged, module: edge cases

### 🐛 Describe the bug


Function `torch.max_unpool3d` contains segmentation fault.

### Example to reproduce

```
import torch

tensor_0 = torch.full([], -10000, dtype=torch.int64, requires_grad=False)
tensor_1 = torch.full([7, 7, 7, 4, 4, 4, 7, 7], -8695, dtype=torch.float16, requires_grad=False)
intarrayref_2 = []
intarrayref_3 = 7052
intarrayref_4 = -9995
torch._C._nn.max_unpool3d(tensor_0, tensor_1, intarrayref_2, intarrayref_3, intarrayref_4)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in grid_sampler_3d
Labels: triaged, module: edge cases

### 🐛 Describe the bug


Function `torch.grid_sampler_3d` contains segmentation fault.

### Example to reproduce

```
import torch

input = torch.full([4, 2, 0, 0, 4, 0, 0, 3], -1480, dtype=torch.float64, requires_grad=False)
grid = torch.full([1, 6, 3, 5, 3, 4, 0, 6], -2024, dtype=torch.float64, requires_grad=False)
interpolation_mode = -3278
padding_mode = -1469
align_corners = True
torch.grid_sampler_3d(input, grid, interpolation_mode, padding_mode, align_corners)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segfault in bincount
Labels: triaged, module: edge cases

### 🐛 Describe the bug

Function `torch.bincount` contains segmentation fault.

### Example to reproduce

```
import torch

self = torch.full([3], 2550, dtype=torch.int64, requires_grad=False)
weights = torch.full([3, 1, 3, 0, 0, 0, 1, 1], -4620, dtype=torch.int64, requires_grad=False)
minlength = 9711
torch.bincount(self, weights, minlength)
```

### Result

Segmentation fault

### Expected Behavior

Throwing a Python Exception

### Notes

This bug was discovered using [Atheris](https://github.com/google/atheris).


### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31
Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
[ONNX] Support tensors as scale and zero_point arguments
Labels: module: onnx, triaged, OSS contribution wanted, onnx-triaged

### 🚀 The feature, motivation and pitch

PyTorch supports using tensors as scale and zero_point arguments. Currently in `test_pytorch_onnx_caffe2_quantized.py`, we get

```
RuntimeError: Expected node type 'onnx::Constant' for argument 'scale' of node 'quantize_per_tensor', got 'prim::Param'.
```

Related:

- https://github.com/pytorch/pytorch/pull/77772

### Alternatives

_No response_

### Additional context

_No response_
RFC: Move functorch into pytorch/pytorch
Labels: triaged

We (some folks from the functorch team, @samdow @Chillee) met with some of the PyTorch GitHub first and dev infra teams (@malfet, @osalpekar, @seemethere)  to discuss pytorch/pytorch and functorch co-development pains.

In that meeting, we identified the following solution, some stakeholders for out-of-tree (@suo) and pytorch core development (@gchanan), CI and developer velocity (@suo, @mruberry), and we are putting this issue up for discussion and to ask for sign-off from the stakeholders.

## Motivation 1: internal build failures

pytorch/pytorch and pytorch/functorch get synced internally at different cadences. Realistically this means that e.g. a deletion to a c++ function in pytorch/pytorch can cause the pytorch/functorch build to fail until it is fixed, leading to downstream failures.


## Motivation 2: co-development is difficult

functorch's CI breaks almost daily due to changes to pytorch/pytorch. There are a number of reasons for this:
- a pytorch/pytorch c++ function is deleted or signature is updated (see Motivation 1)
- a operator implementation is updated
- a developer is co-developing a feature between pytorch/pytorch and pytorch/functorch and is unable to atomically commit to both repos

## Proposal: move functorch into pytorch/pytorch

Our proposal is to "cut-and-paste" (with adjustments as necessary) functorch from pytorch/functorch into a top-level folder in pytorch/pytorch named functorch.

There are a couple of details here:
- **functorch development**: this happens inside pytorch/pytorch/functorch. There will probably be nothing left in the pytorch/functorch repo after the cut-and-paste.
- **Build and release**: functorch will still be packaged separately from pytorch/pytorch
- **CI**: pytorch/pytorch CI will run both pytorch/pytorch and functorch tests. *Developers are responsible for ensuring that both pass*

Why did we choose this? Our eventual plan is to upstream and integrate functorch into pytorch/pytorch. We believe functorch's {transforms, compilation} pieces should be a core part of pytorch/pytorch. Integration is a much larger project and we're looking for a quick stop-gap solution for  the co-development pains, so moving functorch into pytorch/pytorch is a first step towards integration.

## Impact on pytorch/pytorch developers

- **test-cost increase**. functorch build+test takes 1hr on CUDA. If we add new "functorch build+test" jobs to pytorch/pytorch CI, then we'll end up using more resources, but these can be run in parallel to pytorch/pytorch tests.
- **dev-x**. pytorch/pytorch developers are responsible for making sure all functorch build+tests pass. Realistically what this will look like is that if something fails and the developer needs help, then the should loop in someone from functorch and we will assist.

cc-ing some more folks: @vfdev-5, @kshitij12345, @ezyang, @bdhirsh
DISABLED test_init_from_local_shards (__main__.TestShardedTensorFromLocalShards)
Labels: oncall: distributed, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](http://torch-ci.com/failure/test_init_from_local_shards%2C%20TestShardedTensorFromLocalShards) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/6546960161).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 3 red and 5 green.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501 @jjlilley @mrzzd