text:
Problem logging validation loss during the training

🐛 Bug

I am working with a model from PyTorchForecasting and I am training a Temporal Fusion Transformer. I wanted to log the training and validation loss over the epoch for the duration of the training. I saw some other issues but I could not find my answer there.
I have defined a loss_logger as below:
from pytorch_lightning.callbacks import Callback

class LossLogger(Callback):
    def __init__(self):
        self.train_loss = []
        self.val_loss = []

    def on_train_epoch_end(self, trainer: "pl.Trainer", pl_module: "pl.LightningModule") -> None:
        self.train_loss.append(float(trainer.callback_metrics["train_loss"]))

    def on_validation_epoch_end(self, trainer: "pl.Trainer", pl_module: "pl.LightningModule") -> None:
        self.val_loss.append(float(trainer.callback_metrics["val_loss"]))

And I define the trainer as below:
loss_logger_tft = LossLogger()

trainer = pl.Trainer(
    max_epochs = 100,
    gpus=1,
    val_check_interval=1,
    check_val_every_n_epoch=1,
    callbacks=[loss_logger_tft]
)

When I try to fit the trainer, I get the error below:
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
/tmp/ipykernel_26953/1997652008.py in <module>
      3     tft,
      4     train_dataloader=train_dataloader,
----> 5     val_dataloaders=val_dataloader,
      6 )

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in fit(self, model, train_dataloaders, val_dataloaders, datamodule, train_dataloader, ckpt_path)
    739             train_dataloaders = train_dataloader
    740         self._call_and_handle_interrupt(
--> 741             self._fit_impl, model, train_dataloaders, val_dataloaders, datamodule, ckpt_path
    742         )
    743

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _call_and_handle_interrupt(self, trainer_fn, *args, **kwargs)
    683         """
    684         try:
--> 685             return trainer_fn(*args, **kwargs)
    686         # TODO: treat KeyboardInterrupt as BaseException (delete the code below) in v1.7
    687         except KeyboardInterrupt as exception:

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _fit_impl(self, model, train_dataloaders, val_dataloaders, datamodule, ckpt_path)
    775         # TODO: ckpt_path only in v1.7
    776         ckpt_path = ckpt_path or self.resume_from_checkpoint
--> 777         self._run(model, ckpt_path=ckpt_path)
    778
    779         assert self.state.stopped

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _run(self, model, ckpt_path)
   1197
   1198         # dispatch `start_training` or `start_evaluating` or `start_predicting`
-> 1199         self._dispatch()
   1200
   1201         # plugin will finalized fitting (e.g. ddp_spawn will load trained model)

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _dispatch(self)
   1277             self.training_type_plugin.start_predicting(self)
   1278         else:
-> 1279             self.training_type_plugin.start_training(self)
   1280
   1281     def run_stage(self):

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/plugins/training_type/training_type_plugin.py in start_training(self, trainer)
    200     def start_training(self, trainer: "pl.Trainer") -> None:
    201         # double dispatch to initiate the training loop
--> 202         self._results = trainer.run_stage()
    203
    204     def start_evaluating(self, trainer: "pl.Trainer") -> None:

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in run_stage(self)
   1287         if self.predicting:
   1288             return self._run_predict()
-> 1289         return self._run_train()
   1290
   1291     def _pre_training_routine(self):

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _run_train(self)
   1309             self.progress_bar_callback.disable()
   1310
-> 1311         self._run_sanity_check(self.lightning_module)
   1312
   1313         # enable train mode

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _run_sanity_check(self, ref_model)
   1373             # run eval step
   1374             with torch.no_grad():
-> 1375                 self._evaluation_loop.run()
   1376
   1377             self.call_hook("on_sanity_check_end")

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/loops/base.py in run(self, *args, **kwargs)
    149                 break
    150
--> 151         output = self.on_run_end()
    152         return output
    153

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/loops/dataloader/evaluation_loop.py in on_run_end(self)
    132
    133         # hook
--> 134         self._on_evaluation_epoch_end()
    135
    136         # log epoch metrics

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/loops/dataloader/evaluation_loop.py in _on_evaluation_epoch_end(self)
    239         """Runs ``on_{validation/test}_epoch_end`` hook."""
    240         hook_name = "on_test_epoch_end" if self.trainer.testing else "on_validation_epoch_end"
--> 241         self.trainer.call_hook(hook_name)
    242         self.trainer.call_hook("on_epoch_end")
    243         self.trainer.logger_connector.on_epoch_end()

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in call_hook(self, hook_name, pl_module, *args, **kwargs)
   1493             callback_fx = getattr(self, hook_name, None)
   1494             if callable(callback_fx):
-> 1495                 callback_fx(*args, **kwargs)
   1496
   1497             # next call hook in lightningModule

~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/callback_hook.py in on_validation_epoch_end(self)
    101         """Called when the validation epoch ends."""
    102         for callback in self.callbacks:
--> 103             callback.on_validation_epoch_end(self, self.lightning_module)
    104
    105     def on_test_epoch_start(self):

/tmp/ipykernel_26953/966142372.py in on_validation_epoch_end(self, trainer, pl_module)
     12     def on_validation_epoch_end(self, trainer: "pl.Trainer", pl_module: "pl.LightningModule") -> None:
     13 #         print(trainer.callback_metrics)
---> 14         self.val_loss.append(float(trainer.callback_metrics["val_loss"]))

KeyError: 'val_loss'

Interestingly, when I comment out the validation loss in LossLoger class, it runs fine and gives me the training loss. I was wondering where I am going wrong.
Thanks,

from the stack trace:
~/.conda/envs/darts_env/lib/python3.7/site-packages/pytorch_lightning/trainer/trainer.py in _run_train(self)
   1309             self.progress_bar_callback.disable()
   1310
-> 1311         self._run_sanity_check(self.lightning_module)

this must be happening during sanity check since logs are not recorded during sanity check.
can you try:
...
    def on_validation_epoch_end(self, trainer: "pl.Trainer", pl_module: "pl.LightningModule") -> None:
        if not trainer.sanity_checking:
            self.val_loss.append(float(trainer.callback_metrics["val_loss"]))

or
trainer = Trainer(..., num_sanity_val_steps=0)

Thank you so much. That solved the problem.
However, it still gives the validation loss per step not epoch (which I saw in other issues too). Just to make sure, does it make sense to average val_loss over the number of steps in one epoch to get the val_loss per epoch?

it should be the averaged one if you are logging it using self.log(..., on_epoch=True).

repo: PyTorchLightning/pytorch-lightning


text:
Update PipeRPCPlugin compatibility to pytorch 1.7.0+

🚀 Feature

Latest pytorch-lightning supports Sequential Model Parallelism, but compatible only with torch==1.6.0. Supporting 1.7.0+ allows us to exploit latest GPUs such as RTX 3000 series.

Motivation

Fine-tuning models too large for a single GPU.

Pitch

PipeRPCPlugin to support torch==1.7.0 or higher.

Alternatives

pl.Trainer supports accelerator='sharded' option without data-parallelism. (i.e. batch_size=1)

Additional context
N/A

Dear @y-rokutan,
Have you tried PipeRCPPluging. Did it work fine for you ?
I will try to see if it works with 1.7+ and keep you updated.
Best,
T.C

Hi @tchaton.
I've tried PipeRCPPluging on torch==1.8.0.dev20201229+cu110 and pytorch-lightning==1.1.0 (compatible with RTX 3090),
but it shows PipeRPCPlugin requires FairScale and currently is only supported on PyTorch 1.6. error:
(it means FAIRSCALE_AVAILABLE and LooseVersion(torch.__version__) == LooseVersion("1.6.0") is False)
removing  LooseVersion(torch.__version__) == LooseVersion("1.6.0") allows run code without error, but the model doesn't split on GPUs correctly: only GPU_0 voltage/vRam jumps and others doesn't load the model.
BTW, I'm trying to train BERT-like transformer which is too big for a single GPU even if batch_size=1.
If I can set batch_size=1 (i.e. no data-parallelism) and accelerator='ddp_sharding' option for pl.Trainer, it would be a good walkaround.
Does anyone know how to enable sharding without dp?

@y-rokutan mind open a request on FairScale when they make an official release with wider version support?
(and pls link the request here to this issue)

Hi @Borda,
To my understanding, fairscale supports torch==1.7.1 and CUDA=11.0, so fairscale seems not the cause of this issue.
What kind of test can I do to determine where the problem is?

Hey @y-rokutan,
removing LooseVersion(torch.__version__) == LooseVersion("1.6.0") allows run code without error, but the model doesn't split on GPUs correctly: only GPU_0 voltage/vRam jumps and others doesn't load the model.

That's wierd. I look into this.
By the way ddp_sharded does perform model parallelism, but optimizer state and gradient sharding.
Best,
T.C

Hey @y-rokutan,
removing LooseVersion(torch.__version__) == LooseVersion("1.6.0") allows run code without error, but the model doesn't split on GPUs correctly: only GPU_0 voltage/vRam jumps and others doesn't load the model.

That's wierd. I look into this.
By the way ddp_sharded does perform model parallelism, but optimizer state and gradient sharding.
Best,
T.C

Hello,
I am planning to have a few RTX 3090 so I am curious, why does pytorch 1.6 not support this card?
Also,

By the way ddp_sharded does perform model parallelism, but optimizer state and gradient sharding.
Indeed but if the issue is the activations (as in computer vision applications) then it does not help.

I am planning to have a few RTX 3090 so I am curious, why does pytorch 1.6 not support this card?

think that you should ask them :]
so far I know the recommendation is to use PT 1.8
you could also have a question about py3.9 compatibility for older PT versions :]

I am planning to have a few RTX 3090 so I am curious, why does pytorch 1.6 not support this card?

think that you should ask them :]
so far I know the recommendation is to use PT 1.8
you could also have a question about py3.9 compatibility for older PT versions :]

I figured it out: https://pytorch.org/docs/stable/notes/cuda.html#tf32-on-ampere
TensorFloat support is only available starting from pytorch 1.7+ and from the new generation of NVIDIA GPUs (Ampere)

Dear @y-rokutan,
Closing this PR as SequentialPlugin will be deprecated.
Best,
T.C

source: gharchive/issue

authors: Borda SebastienEske tchaton y-rokutan

license_type: permissive

license_source: github-api


text:
complex support in all dwt and idwt related functions

This PR adds complex dtype support to downcoef, upcoef, dwt, idwt and by extension, their corresponding multidim and multilevel variants.  This is useful for magnetic resonance imaging applications where images are often stored with both magnitude and phase information.
The same strategy can easily be applied to the stationary wavelet transforms as well.
This is an implementation of option 2 as discussed in #96.  any feedback appreciated

Minor comments, but overall looks good to me.

@kwohlfahrt: I made the stylistic change you suggested.  I will set up a separate PR with some dtype tests.

@grlee77 can you rebase now that #106 is merged?

@ aaren
I rebased and added two small commits.
1.) add complex support to swt for completeness
2.) add complex dtypes to the dtype tests introduced in #106
I think it should now be ready to merge.

Is this a fair summary?

This PR adds complex support to all (?) transforms.
Complex support is implemented by running the Re and Im parts separately through the transform and then recombining.
This functionality might be altered in future by native complex support in the C.

@aaren:  yes.  good summary
I think I have implemented it in all transforms now.
For dwtn / idwtn it would probably speed up computation if I did the real/imag split at the top of those functions too rather than having each individual call to dwt or idwt keep doing its own conversion.

@grlee77 I'll merge for now and we can have another PR if it causes performance issues.

source: gharchive/pull-request

authors: aaren grlee77 kwohlfahrt

repo: PyWavelets/pywt

license: mit

license_source: bigquery


text:
add dataviewer

Continuation of #158.
@unga @core

nice, you mind if we put all of this stuff in a different repo ?
Like qcodes-utils ?

Fine with me. @giulioungaretti

thanks, make a PR to here : https://github.com/QCoDeS/tools

authors: giulioungaretti peendebak

repo: QCoDeS/Qcodes

license: MIT


text:
to_matrix and to_spmatrix methods for Pauli class

add a method in Pauli class to generate sparse matrix and revise the to_matrix method.
Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Thanks, @chunfuchen !

repo: QISKit/qiskit-sdk-py


text:
Jenkins: Not able to fetch github project in Jenkins

I've installed Jenkins 2.127 version in my Windows 7 64 bit Operating system. When I try to create a free style project , I'm copying a github url and pasting in source code management section. But the following error is coming.
Please check below.

The following is the console output.

I've Git and Maven installed in my system.
Thank you.

Is your machine connected to internet  while you are executing this

Yes it is.
On Tuesday, June 19, 2018, shaikkhajaibrahim notifications@github.com
wrote:

Is your machine connected to internet while you are executing this
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/41#issuecomment-398284304,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AmAeHWMe5DCHfb974W82cOUdR9AEBLN3ks5t-JRhgaJpZM4UpURx
.

configure the git path in manage jenkins ->configure system and try it.

Resolved??

Closed?

repo: QT-DevOps/DevOpsIssues


text:
#update PMS EXAMPLE

QUANTAXIS PR 😇
感谢您对于QUANTAXIS的项目的参与~ 🛠请在此完善一下最后的信息~
注意

如果非第一次fork, 请先将quantaxis 库的内容PR进您的项目进行更新, 然后再执行对于quantaxis的pr
请完善CHANGELOG再进行PR

PR前必看
请使用如下代码对要PR的代码进行格式化:
qa的 yapf格式也是从vnpy那拿来的 参见 https://github.com/vnpy/vnpy/blob/v2.0-DEV/.style.yapf
使用以下代码来格式化
pip install https://github.com/google/yapf/archive/master.zip
yapf -i --style .style.yapf <file>

🛠该PR主要解决的问题🛠:
作者信息:
时间:

Hello @yutiansut! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file QUANTAXIS/Exp/asyncschedule.py:

Line 135:1: E302 expected 2 blank lines, found 1
Line 143:58: W292 no newline at end of file

In the file QUANTAXIS/Exp/asynctask.py:

Line 1:1: W293 blank line contains whitespace
Line 130:56: W292 no newline at end of file

In the file QUANTAXIS/QAMarket/QAPosition.py:

Line 411:26: E231 missing whitespace after ':'
Line 413:1: W293 blank line contains whitespace
Line 414:29: E231 missing whitespace after ':'

repo: QUANTAXIS/QUANTAXIS


text:
中搞

您好！我想引用您的文章，在谷歌学术上面显示还是预印版，是现在还在审稿阶段吗

@creater-zq 目前论文还在审理中，可以引用arxiv的版本，感谢！


text:
插件继承宿主Activity时，插件内访问不到插件layout资源

#720 ### 问题详细描述 Detailed description of the problem

在插件Activity 继承 宿主一个重写Activity后，插件中的setContentView(R.layout.activity_main)会报错，找不到资源(这个资源位于插件项目res/layout中)
取消继承宿主Activity 则不会报错

复现问题步骤 Steps to reproduce the problem

宿主类：ReturnableActivityToolbar带返回图标的Activity

@SuppressLint("Registered")
open class ReturnableActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        supportActionBar?.setDisplayHomeAsUpEnabled(true)
    }

    override fun onOptionsItemSelected(item: MenuItem?): Boolean {
        if (item?.itemId == android.R.id.home) {
            finish()
            return true
        }
        return super.onOptionsItemSelected(item)
    }
}

插件PluginMainActivity继承ReturnableActivity

class PluginMainActivity : ReturnableActivity() {//继承宿主ReturnableActivity

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)//此处报错 找不到资源 ，这个资源位于插件项目res/layout中
   }
}

其它重要信息 Other important information
replugin-host-lib/gradle Version:2.3.1
rePlugin-plugin-lib/gradle Version:2.3.1
Android API Version：Android 8.0
Android 手机型号&ROM(Phone model & ROM): 一加5 氢OS
Logcat上下文 Logcat context

楼主如何解决的  能说下吗？

同问下，真是无语，被这个卡了好久


text:
服务器崩溃 原因没看懂

首先，pika的服务器是在linux下  centos7   安装官网说明操作安装的
其次，测试的客户端是windows下的redis-cli
问题描述：当redie-cli连接上服务器的pika后     输入  set index 111   回车后  服务器上的pika崩溃  具体报错见图(包含gdb调试错误)；
pika服务器崩溃
http://upload-images.jianshu.io/upload_images/5712448-9f0259de1d456181.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
windows 操作（linux下也测试了同样的结果）
http://upload-images.jianshu.io/upload_images/5712448-ad5c3209b05b82d7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
http://upload-images.jianshu.io/upload_images/5712448-5facc7b08c7ea67f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
gdb 跟踪报错
http://upload-images.jianshu.io/upload_images/5712448-c4b114b0ae7801f1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
日志信息
http://upload-images.jianshu.io/upload_images/5712448-2e930309b122aec0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240
直接上传图片不知道什么原因报错  尴尬啊！
如问题描述的不够详细  可找我补充  谢谢

链接 放地址栏访问 尴尬啊

Pika module 2.2.6

gdb报错在pink的src/redis_conn.cc:328行，但内容不正常，怀疑是pink submodule没有更新到响应的版
本，在pika目录下
make distclean
git submodule update
make

重新编译一下试试
或者直接使用我们编译好的二进制，或者docker镜像，在release里可以下载

authors: freeaswind gaodq


text:
Memory Usage Increases with Number of Steered Heads

Hi, I'm hitting OOM exceptions on a 40GB A100 when trying to steer more than a few heads at a time.
When steering 32 heads (an entire layer in my case) I use almost all of the GPU memory, and when steering just a single head I use very little memory.
Is this memory usage inherent PASTA's algorithm?

Hi, PASTA should not incur high memory footprint because it only registered a forward_pre_hook to change the attention_mask of attention module inputs (see here). The forward pass is not changed and there is no additional parameters introduced. From our empirical results, it show the same memory consumption as baseline models.

I confirmed that with small sized inputs like the one in the readme there is no noticeable memory consumption increase.
For my application I'm running very large sized inputs (~4k tokens) and there does appear to be a moderate increase in memory usage (from ~1gb at 1 head steered to ~10gb at 1024 heads steered), but now it seems to me that this isn't an issue with the PASTA code and more likely has to do with something in a lower level library.
Thanks for your quick response.

I was able to trace this issue back to this bit of code in the edit_attention_mask method:
        if head_dim != self.num_attn_head:
            attention_mask = attention_mask.expand(
                bsz, self.num_attn_head, tgt_len, src_len
            ).clone()

Specifically, it seems that cloning the attention mask causes a very slight memory leak that is only apparent with huge input sizes. Removing the .clone() fixes this, but produces a deprecation warning:
UserWarning: Use of index_put_ on expanded tensors is deprecated. Please clone() the tensor before performing this operation. This also applies to advanced indexing e.g. tensor[indices] = tensor (Triggered internally at ../aten/src/ATen/native/TensorAdvancedIndexing.cpp:713.)

@Spongeorge I believe removing .clone() would lead to errors since in-place operations would then modify data in the same memory location (as expand only changes the view of the tensor and does not make a copy). The cloning is unfortunately necessary since PASTA needs to maintain a separate copy of attention mask for each head, in-order to intervene the heads independently.

authors: QingruZhang Spongeorge jybai

repo: QingruZhang/PASTA


text:
Replace deprecated test providers

Fixes #1225
See client verify processes (3.8, 3.9, 3.10) are now passing.
Summary
Followed replacement chart in this qiskit PR.
Note the replacement chart above only has instructions for replacing FakeAlmaden to Fake20QV1.
FakeBrooklyn has been replaced by a generic fake provider GenericBackendV2.

Closing this PR as #1225 is also being addressed in #1227.

repo: Qiskit-Extensions/quantum-serverless


text:
Figure out URL and folder structure for API versioning

Background
Part of https://github.com/Qiskit/documentation/issues/77. We need historical versions for the API docs, like Qiskit 0.24 vs 0.25. Distinct versions will be for minor releases, but not patch releases like 0.24.1.
The non-API docs do not have versioning per-API. Instead, https://github.com/Qiskit/documentation/issues/133 tracks how we will indicate in non-API docs their version compatibility. This ticket is focused on API docs.
Relationship to translations
API docs have not ever been historically translated and we don't plan to in the future, per @SooluThomas.
So, while the folder structure we use for translations (https://github.com/Qiskit/docs/issues/7) is relevant, it's somewhat orthogonal.
Plan
/api/qiskit/<version>/, e.g. /api/qiskit/0.25/circuit
This URL scheme corresponds to the folder structure, that we'll have a folder api/qiskit/0.25 etc. That folder will be self-contained, e.g. with its own _toc.json. When in the frontend the user changes the currently selected version, we'll switch to rendering that folder.
Cross-references
We need to update cross-references for stable version folders so that they all link to files in the same version folder, i.e. 0.25 files all cross-link to 0.25 files.
This will be automated by our API generation script.
Keep un-versioned API
We'll also continue having an un-versioned "latest" URL, like /api/qiskit/circuit, so that people can link to latest.
When generating the API docs for the "latest", it will update both the stable folder and the unstable folders so that they're in sync.
None of our API pages start with a number—which would be a violation of Python naming rules—so we shouldn't have a clash between the version folder and the unversioned docs.
Non-API docs will link to the un-versioned docs in most cases, other than specific edge cases like how qiskit.algorithms is being deleted, so the Algorithms migration guide must link to the historical file.

@axelhzf thought through how best to integrate this with the web app. Each folder, including the top-level one for current, will have a _package.json file, similar to _toc.json. it will simply be this:
{
  "name": "qiskit",
  "version": "0.25.0"
}

Folder structure:
qiskit
├── 0.24.0
│   ├── _package.json
│   ├── _toc.json
│   └── ...  // content files for this version
├── _package.json
├── _toc.json
└── ... // content files for the latest version

He got this working in the web app (thank you!). So all that remains is in this repository improving the generation script to add these folders and the _package.json files, tracked by https://github.com/Qiskit/documentation/issues/77

repo: Qiskit/documentation


text:
Indicate that a backend supports splitting a job?

What is the expected enhancement?
In qiskit-experiments (which works with qiskit-ibmq-provider but not qiskit-ibm-provider at the moment), there is support for splitting up a large experiment into multiple jobs if there are too many circuits:
https://github.com/Qiskit/qiskit-experiments/blob/887309c4aa6084afa954e711b301dc3eeb0183f0/qiskit_experiments/framework/base_experiment.py#L334-L345
qiskit-ibm-provider has similar functionality:
https://github.com/Qiskit/qiskit-ibm-provider/blob/c6b63e19623cec8817cc3a110c3ca4e92dd95037/qiskit_ibm_provider/ibm_backend.py#L517-L539
So it would probably be best for qiskit-experiments not to split jobs for qiskit-ibm-provider. I opened https://github.com/Qiskit/qiskit-experiments/issues/723 about this but what I was not sure about was how to detect if a backend supported job splitting itself or not. Do you think it would make sense to add an extra attribute to the backend like supports_split_large_job that  qiskit-experiments could check before deciding to split a job into max_experiments chunks?

As mentioned in the experiments issue, if the backend doesn't have a max_experiments property, it supports job splitting on its own.

max_experiments (max_circuits) is a backend configuration that says the maximum number of circuits the backend supports in a job. It is not a provider configuration, and IBM provider doesn't overwrite that value. This means if max_experiments=10 and you submit a job with 100 circuits, IBM provider will divide that for you. I think the original issue in qiskit-experiments is to find a way to determine whether the provider (not the backend) does the splitting?

@jyu00 yes, that's right. I have some terminology crossed here because I was using "backend" to refer to an object that is a subclass of Backend rather than the service behind the provider. I was thinking the solution was that IBMBackend would report None for max_experiments/max_circuits to indicate there was no limit since it can split a larger job. Looking again, I see that it will just return the number that came from the configuration. So I will reopen with "backend" replaced with "provider".
By the way, something else I notice looking at max_circuits -- it looks like IBMBackend.max_circuits is intended to be read-only. With qiskit-ibmq-provider, I sometimes modify IBMQBackend.configuration().max_experiments because I think the value is only a suggested good number rather than a hard limit and sometimes a different number works better for splitting jobs (https://github.com/Qiskit/qiskit-experiments/issues/638).

I think the value is only a suggested good number rather than a hard limit and sometimes a different number works better for splitting jobs (Qiskit/qiskit-experiments#638).

It is a hard upper limit, and your job will fail validation if it contains more circuits than what max_circuits allows. It is immutable because it's a system-defined attribute. You can use the max_circuits_per_job keyword to set a different number, and IBM provider will use the smaller of that number and system limit.

repo: Qiskit/qiskit-ibm-provider


text:
Bump min terra version to 0.21.0

Summary
Bump min terra version to 0.21.0 (since earlier versions are not compatible with latest of qiskit-ibm-runtime).
Details and comments
Fixes #428

Pull Request Test Coverage Report for Build 2692371622

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 62.366%

Totals

Change from base Build 2678278321:
0.0%

Covered Lines:
2857

Relevant Lines:
4581

💛  - Coveralls

authors: coveralls rathishcholarajan

repo: Qiskit/qiskit-ibm-runtime


text:
Temporary Remove Python 3.6 from CI

Summary
Terra 0.20 removed python 3.6 support. Since we cannot do it in the main branch until we release 0.3.0, I am temporarily removing it from the CI. After release I will have to put it back on the branch stable/0.3 and then python 3.6 support will be definitely removed from main.
Details and comments

Pull Request Test Coverage Report for Build 1547203743

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage remained the same at 85.342%

Files with Coverage Reduction
New Missed Lines
%

qiskit_nature/drivers/psi4d/psi4driver.py
1
87.18%

qiskit_nature/drivers/second_quantization/psi4d/psi4driver.py
1
86.47%

Totals

Change from base Build 1539286459:
0.0%

Covered Lines:
9671

Relevant Lines:
11332

💛  - Coveralls

authors: coveralls manoelmarques

repo: Qiskit/qiskit-nature


text:
transpiler changes layout of already mapped circuit

Information

Qiskit Terra version: 0.7.1
Python version: 3.6.6
Operating system: Windows 10

What is the current behavior?
circuit before compile
               ┌───┐                             ┌───┐ ░    ┌─┐
 qn_0: |0>─────┤ H ├──■──────────────────■───────┤ H ├─░────┤M├
               └───┘  │                  │       └───┘ ░    └╥┘
 qn_1: |0>────────────┼──────────────────┼─────────────░─────╫─
                      │                  │             ░     ║
 qn_2: |0>────────────┼──────────────────┼─────────────░─────╫─
                      │                  │             ░     ║
 qn_3: |0>────────────┼──────────────────┼─────────────░─────╫─
                      │                  │             ░     ║
 qn_4: |0>────────────┼──────────────────┼─────────────░─────╫─
          ┌───┐     ┌─┴─┐┌────────────┐┌─┴─┐┌───┐      ░ ┌─┐ ║
 qn_5: |0>┤ H ├─────┤ X ├┤ U1(6.2832) ├┤ X ├┤ H ├──────░─┤M├─╫─
          └───┘     └───┘└────────────┘└───┘└───┘      ░ └╥┘ ║

circuit above is truncated from full device size
circuit after compile
                         ┌──────────────┐     ┌───┐
 q_0: |0>────────────────┤ U2(0,3.1416) ├──■──┤ X ├──■───────────────────────────────────────────────────────────────────
                         └──────────────┘  │  └─┬─┘  │
 q_1: |0>──────────────────────────────────┼────┼────┼───────────────────────────────────────────────────────────────────
                                           │    │    │
 q_2: |0>──────────────────────────────────┼────┼────┼───────────────────────────────────────────────────────────────────
                                           │    │    │
 q_3: |0>──────────────────────────────────┼────┼────┼───────────────────────────────────────────────────────────────────
                                           │    │    │
 q_4: |0>──────────────────────────────────┼────┼────┼───────────────────────────────────────────────────────────────────
                                         ┌─┴─┐  │  ┌─┴─┐                                        ┌──────────────┐ ░    ┌─┐
 q_5: |0>────────────────────────────────┤ X ├──■──┤ X ├──■──────────────────■──────────────────┤ U2(0,3.1416) ├─░────┤M├
                                         └───┘     └───┘  │                  │                  └──────────────┘ ░    └╥┘
 q_6: |0>─────────────────────────────────────────────────┼──────────────────┼─────────────────────────────────────────╫─
                                                          │                  │                                         ║
 q_7: |0>─────────────────────────────────────────────────┼──────────────────┼─────────────────────────────────────────╫─
                                                          │                  │                                         ║
 q_8: |0>─────────────────────────────────────────────────┼──────────────────┼─────────────────────────────────────────╫─
                                                          │                  │                                         ║
 q_9: |0>─────────────────────────────────────────────────┼──────────────────┼─────────────────────────────────────────╫─
         ┌──────────────┐                               ┌─┴─┐┌────────────┐┌─┴─┐┌──────────────┐                 ░ ┌─┐ ║
q_10: |0>┤ U2(0,3.1416) ├───────────────────────────────┤ X ├┤ U1(6.2832) ├┤ X ├┤ U2(0,3.1416) ├─────────────────░─┤M├─╫─
         └──────────────┘                               └───┘└────────────┘└───┘└──────────────┘                 ░ └╥┘ ║

Steps to reproduce the problem
[0,5] and [5,10] are both in the device coupling map, default transpile remaps even though the circuit is already mapped
What is the expected behavior?
precompiled and compiled circuits should be the same
Suggested solutions
temporary workaround: provide explicit 1 to 1 initial_layout

I was not able to reproduce this.
In master:
from qiskit import QuantumRegister, QuantumCircuit, ClassicalRegister, transpiler
import numpy as np

q = QuantumRegister(6, name='qn')
c = ClassicalRegister(2, name='cn')

zz = QuantumCircuit(q, c)
zz.h(q[0])
zz.h(q[5])
zz.cx(q[0], q[5])
zz.u1(2 * np.pi, q[5])
zz.cx(q[0], q[5])
zz.h(q[0])
zz.h(q[5])
zz.barrier(q)
zz.measure(q[0], c[0])
zz.measure(q[5], c[1])

print(zz)
new_zz = transpiler.transpile(zz, basis_gates=['u1', 'u2', 'u3', 'cx', 'id'],
                              coupling_map=[[0, 1], [0, 5], [1, 0], [1, 2], [2, 1], [2, 3],
                                            [3, 2], [3, 4], [4, 3], [4, 9], [5, 0], [5, 6],
                                            [5, 10], [6, 5], [6, 7], [7, 6], [7, 8], [7, 12],
                                            [8, 7], [8, 9], [9, 4], [9, 8], [9, 14], [10, 5],
                                            [10, 11], [10, 15], [11, 10], [11, 12], [12, 7],
                                            [12, 11], [12, 13], [13, 12], [13, 14], [14, 9],
                                            [14, 13], [14, 19], [15, 10], [15, 16], [16, 15],
                                            [16, 17], [17, 16], [17, 18], [18, 17], [18, 19],
                                            [19, 14], [19, 18]])
print(new_zz)

         ┌───┐                        ┌───┐ ░ ┌─┐
qn_0: |0>┤ H ├──■──────────────────■──┤ H ├─░─┤M├────
         └───┘  │                  │  └───┘ ░ └╥┘
qn_1: |0>───────┼──────────────────┼────────░──╫─────
                │                  │        ░  ║
qn_2: |0>───────┼──────────────────┼────────░──╫─────
                │                  │        ░  ║
qn_3: |0>───────┼──────────────────┼────────░──╫─────
                │                  │        ░  ║
qn_4: |0>───────┼──────────────────┼────────░──╫─────
         ┌───┐┌─┴─┐┌────────────┐┌─┴─┐┌───┐ ░  ║ ┌─┐
qn_5: |0>┤ H ├┤ X ├┤ U1(6.2832) ├┤ X ├┤ H ├─░──╫─┤M├─
         └───┘└───┘└────────────┘└───┘└───┘ ░  ║ └╥┘

         ┌──────────────┐          ┌──────────────┐ ░ ┌─┐
 q_0: |0>┤ U2(0,3.1416) ├──■────■──┤ U2(0,3.1416) ├─░─┤M├────
         └──────────────┘  │    │  └──────────────┘ ░ └╥┘
 q_1: |0>──────────────────┼────┼───────────────────░──╫─────
                           │    │                   ░  ║
 q_2: |0>──────────────────┼────┼───────────────────░──╫─────
                           │    │                   ░  ║
 q_3: |0>──────────────────┼────┼───────────────────░──╫─────
                           │    │                   ░  ║
 q_4: |0>──────────────────┼────┼───────────────────░──╫─────
         ┌──────────────┐┌─┴─┐┌─┴─┐┌──────────────┐ ░  ║ ┌─┐
 q_5: |0>┤ U2(0,3.1416) ├┤ X ├┤ X ├┤ U2(0,3.1416) ├─░──╫─┤M├─
         └──────────────┘└───┘└───┘└──────────────┘ ░  ║ └╥┘

In 0.7.1:
from qiskit import QuantumRegister, QuantumCircuit, ClassicalRegister, transpiler
import numpy as np

q = QuantumRegister(6, name='qn')
c = ClassicalRegister(2, name='cn')

zz = QuantumCircuit(q, c)
zz.h(q[0])
zz.h(q[5])
zz.cx(q[0], q[5])
zz.u1(2 * np.pi, q[5])
zz.cx(q[0], q[5])
zz.h(q[0])
zz.h(q[5])
zz.barrier(q)
zz.measure(q[0], c[0])
zz.measure(q[5], c[1])

print(zz)
new_zz = transpiler.transpile(zz, basis_gates='u1, u2, u3, cx, id',
                              coupling_map=[[0, 1], [0, 5], [1, 0], [1, 2], [2, 1], [2, 3],
                                            [3, 2], [3, 4], [4, 3], [4, 9], [5, 0], [5, 6],
                                            [5, 10], [6, 5], [6, 7], [7, 6], [7, 8], [7, 12],
                                            [8, 7], [8, 9], [9, 4], [9, 8], [9, 14], [10, 5],
                                            [10, 11], [10, 15], [11, 10], [11, 12], [12, 7],
                                            [12, 11], [12, 13], [13, 12], [13, 14], [14, 9],
                                            [14, 13], [14, 19], [15, 10], [15, 16], [16, 15],
                                            [16, 17], [17, 16], [17, 18], [18, 17], [18, 19],
                                            [19, 14], [19, 18]], initial_layout = {("qn", 0): ("q", 0), ("qn", 1): ("q", 1),
                          ("qn", 2): ("q", 2), ("qn", 3): ("q", 3), ("qn", 4): ("q", 4), ("qn", 5): ("q", 5)})

print(new_zz)

              ┌───┐                             ┌───┐ ░    ┌─┐
qn_0: |0>─────┤ H ├──■──────────────────■───────┤ H ├─░────┤M├
              └───┘  │                  │       └───┘ ░    └╥┘
qn_1: |0>────────────┼──────────────────┼─────────────░─────╫─
                     │                  │             ░     ║
qn_2: |0>────────────┼──────────────────┼─────────────░─────╫─
                     │                  │             ░     ║
qn_3: |0>────────────┼──────────────────┼─────────────░─────╫─
                     │                  │             ░     ║
qn_4: |0>────────────┼──────────────────┼─────────────░─────╫─
         ┌───┐     ┌─┴─┐┌────────────┐┌─┴─┐┌───┐      ░ ┌─┐ ║
qn_5: |0>┤ H ├─────┤ X ├┤ U1(6.2832) ├┤ X ├┤ H ├──────░─┤M├─╫─
         └───┘     └───┘└────────────┘└───┘└───┘      ░ └╥┘ ║

                               ┌────────────────────┐                        ┌────────────────────┐                       ░ ┌─┐
 q_0: |0>──────────────────────┤ U(1.5708,0,3.1416) ├──■──────────────────■──┤ U(1.5708,0,3.1416) ├───────────────────────░─┤M├───
                               └────────────────────┘  │                  │  └────────────────────┘                       ░ └╥┘
 q_1: |0>──────────────────────────────────────────────┼──────────────────┼──────────────────────────────────────────────────╫────
                                                       │                  │                                                  ║
 q_2: |0>──────────────────────────────────────────────┼──────────────────┼──────────────────────────────────────────────────╫────
                                                       │                  │                                                  ║
 q_3: |0>──────────────────────────────────────────────┼──────────────────┼──────────────────────────────────────────────────╫────
                                                       │                  │                                                  ║
 q_4: |0>──────────────────────────────────────────────┼──────────────────┼──────────────────────────────────────────────────╫────
         ┌────────────────────┐                      ┌─┴─┐┌────────────┐┌─┴─┐                      ┌────────────────────┐ ░  ║ ┌─┐
 q_5: |0>┤ U(1.5708,0,3.1416) ├──────────────────────┤ X ├┤ U1(6.2832) ├┤ X ├──────────────────────┤ U(1.5708,0,3.1416) ├─░──╫─┤M├
         └────────────────────┘                      └───┘└────────────┘└───┘                      └────────────────────┘ ░  ║ └╥┘

cmap_hedwig = hedwig.configuration().coupling_map
numq = 20
rounds = 256
q = QuantumRegister(numq, name='qn')
c = ClassicalRegister(numq, name='cn')
steps = 20

zz_circuits = []
for bond in [cmap_hedwig[1]]:
    for ang in np.linspace(0, 2*np.pi, steps, endpoint=True):
        qzz = [q[i] for i in bond]
        czz = [c[i] for i in bond]
        zz = QuantumCircuit(q,c)
        zz.h(qzz[0])
        zz.h(qzz[1])
        zz.cx(qzz[0],qzz[1])
        zz.u1(ang,qzz[1])
        zz.cx(qzz[0],qzz[1])
        zz.h(qzz[0])
        zz.h(qzz[1])
        zz.barrier(q)
        zz.measure(qzz[0],czz[0])
        zz.measure(qzz[1],czz[1])
#         zz.measure(q,c)
        zz_circuits.append(zz)

# zz_compile = qiskit.compile(zz_circuits, backend=hedwig, shots=rounds, coupling_map=cmap_hedwig,
#                            initial_layout=il_hedwig)
zz_compile = qiskit.compile(zz_circuits, backend=hedwig, shots=rounds)
zz_job = hedwig.run(zz_compile)
print(zz_job.job_id())
zz_result = zz_job.result()

This issue is reproducible only when the cirucuit is submitted to the device.
I found the source of error: the barrier is considered in the check for circuit compatibility to the coupling_map. But only gates should be. I will push a fix.

repo: Qiskit/qiskit-terra


text:
Optim level 2 and 3 modifiy circuits that match topology

Information

Qiskit Terra version: master
Python version:
Operating system:

What is the current behavior?
The following circuit fits Vigo-like topologies exactly:

But optimization level 3 gives:

Where as the default gives the expected original circuit (save for H -> U2):

Steps to reproduce the problem

qc = QuantumCircuit(5)
qc.h(3)
qc.cx([3, 3, 1, 1], [1, 4, 2, 0])
qc.measure_all()
new_qc = transpile(qc, backend, optimization_level=3)
new_qc.draw(output='mpl')

What is the expected behavior?
Suggested solutions

It seems like TrivialLayout was not  an attempt before DenseLayout. https://github.com/Qiskit/qiskit-terra/pull/3324 could be a solution to this. https://github.com/Qiskit/qiskit-terra/pull/3043 is also an option. @ajavadia ?
It's important to notice that neither TrivialLayout nor CSPLayout are noise aware (yet).

In PR #3391 I implemented the second approach, using CSPLayout (which resorts to the trivial layout if that's the only possible map).


text:
add new tutorial sections to docs

Summary
Adds algorithms and ML sections to the tutorials.
Details and comments

@SooluThomas  this automatically picks up the new theme version.  And it is fixed in the artifact docs.

repo: Qiskit/qiskit


text:
LastFM integration

Awesome project, congratulations. Are possible an integration with lastfm service ?
Congratulation again, []'s.

@ezefranca I never thought about that.. I will verify if it's possible and update you on it (:

authors: Quaggie ezefranca

repo: Quaggie/Quaggify


text:
gridmake speed

I have tried to rewrite a version of gridmake, that would output a column-major ordering. The following function does it:
function ggmake(nodes...)
       res = [Base.product(nodes...)...]
       reinterpret(Float64, res, (length(res[1]), length(res)))
end

Nice thing about the product generator is it works with any kind of argument as long as it is an iterable collection of floats. For instance ggmake((1.,2.),[0.1,0.2], linspace(0,1,100)) is perfectly valid.
Then I was surprised to see it was significantly faster than the one shipped in Quantecon:
julia> a1, a2, a3 = randn(10), randn(10), randn(10);
julia> @btime ggmake(a1,a2,a3);
  26.409 μs (1016 allocations: 71.22 KiB)
julia> @btime gridmake(a1,a2,a3);
  1.267 ms (11501 allocations: 289.47 KiB)

This is true even if one adds a transposition at the end to replicate hte output of the current gridmake.
@btime ggmake(a1,a2,a3)';
  34.871 μs (1018 allocations: 94.73 KiB)

That makes me wonder, given that the code in https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/util.jl is a fair bit more involved.
Also, the timings in https://github.com/QuantEcon/QuantEcon.jl/pull/104 don't seem consistent with the current measurement. Is there a regression ?

Like always, I sent the comment before editing it completely. I just finished it.

Wow, this is great. Faster and simpler. I'm all for this change.
What should the API look like for choosing tall vs wide output (they are both column major IMO because even in the tall form the first column's values move faster)?
We could have two functions with slightly different names, or we could have a Bool keyword argument. I'm open to suggestions.

I may have been a bit too eager...
Two things to be aware of:

We shouldn't hard code Float64
We need to preserve the current functionality when using AbstractMatrix as an input (see below)

julia> x = [1.0 2.0; 3.0 4.0];

julia> y = [100.0; 200.0]
2-element Array{Float64,1}:
 100.0
 200.0

julia> gridmake(x, y)
4×3 Array{Float64,2}:
 1.0  2.0  100.0
 3.0  4.0  100.0
 1.0  2.0  200.0
 3.0  4.0  200.0

julia> ggmake(x, y)'
8×2 Array{Float64,2}:
 1.0  100.0
 3.0  100.0
 2.0  100.0
 4.0  100.0
 1.0  200.0
 3.0  200.0
 2.0  200.0
 4.0  200.0

indeed. There is still the constraint that data must be homogenous. It's a tricky one, since there is no abstract iterable type. One could use AbstractArray, but that is less general. Don't know what is meant by "traits" in this discussion: https://github.com/JuliaLang/julia/issues/23429
I haven't thought carefully about that one. But maybe it isn't that useful, if not used for recursively defining cartesian products.
As for the transposition, it seems to me, gridmake has a distinctive compecon connotation, and it would be confusing to have it return a column-major result. and gridmake(..., true) to have Julia-friendly ordering would seem strange to me (since it should be the default.

This may be related or may be orthogonal: Yesterday I was wanting gridmake(T::Type, arrays...) to force the eltype of the output to be Float64 independent of the eltype of arrays (one could use gridmake!(out, arrays...) by calculating the shape of out from arrays, but it would be redundant, being done internally in gridmake).

I tried a few approaches and I think the mapreduce(f, hcat, zip(arrays, cumprod)) version offered same order of efficiency and simpler code.

@Nosferican can you point us to the mapreduce version?

authors: Nosferican albop oyamad sglyon


text:
Add check to allow empty arguments to mamba

Currently if one simply does mamba, the result is an IndexError: tuple index out of range.  Regular conda instead yields the equivalent of conda --help.  I suspect this is just a bug, so this PR does what I think is the natural fix to ensure the standard conda behavior if no argument is given.

Awesome, thanks!

authors: eteq wolfv

repo: QuantStack/mamba


text:
Other distributions than the normal distribution

Hey folks,
On  boost::random there are many useful distributions, is there a fast way to utilize them in the xrandom module?
Thanks!

Hi @volkerkarle
if you look at the implementation in xrandom.hpp:
https://github.com/QuantStack/xtensor/blob/777352dbdee82228f3095aa250810dc9153cf26a/include/xtensor/xrandom.hpp#L187-L192
You'll hopefully find it easy to implement more distributions. Please note that a lot of the boost::random distributions have made it into the STL.
We'd appreciate a PR for more random distributions!

If nobody has already done it I can implement the rest of the distributions in

That would be great!

This has been implemented in #1708

authors: JohanMabille jvce92 volkerkarle wolfv

repo: QuantStack/xtensor


text:
Broadcast assign of higher dim container doesn't throw

We currently allow broadcasting a higher dim container into a lower dim view.
However, the result is somewhat unexpected as it looks like broadcast assigning a scalar.
    xarray<double> x0 = {{1,2,3,4,5}, {6,7,8,9,10}, {11,12,13,14,15}};
    auto v1 = view(x0, range(0, 2), range(0, 2));
    xarray<double> x1 = {{{10,20}, {30,40}}};

    std::cout << v1 << std::endl;
    std::cout << x1 << std::endl;

    v1 = x1;

    std::cout << v1 << std::endl;
    std::cout << x0 << std::endl;

E.g this code assigns 10 into x0 (result equiv to v1 = 10)
Maybe we should use XTENSOR_ASSERT to make sure the broadcasting dimensions make sense.

Also this behavior differs from NumPy where the following code works:
>>> import numpy as np
>>> np.array([[1,2,3,4],[5,6,7,8],[9,10,11,12]])
array([[ 1,  2,  3,  4],
       [ 5,  6,  7,  8],
       [ 9, 10, 11, 12]])
>>> a = _
>>> a[0:2, 0:2]
array([[1, 2],
       [5, 6]])
>>> a[0:2, 0:2] = np.array([[[10, 11],[12,13]]])
>>> a
array([[10, 11,  3,  4],
       [12, 13,  7,  8],
       [ 9, 10, 11, 12]])


text:
WIP Partition argpartition

still needs test and docs.

Still needs some boat loads of tests ...

Hey,
I was wondering will this be merged soon or would I be best off forking to use the changes for the time being?
Thanks so much!

@khanley6 I just rebased the branch on master... now it needs some tests

I was going to write some tests but I am unable to build your wolfv:partition_argpartition fork. I get the following error when calling argpartition;
.../xtensor/include/xtensor/xsort.hpp:668:37: error: function 'forward_sequence<std::array<unsigned long, 1>, unsigned long const (&)[1]>' with deduced return type
      cannot be used before it is defined
        return argpartition(e, xtl::forward_sequence<std::array<std::size_t, N>>(kth_container), axis);

I'm building the tests with the master branch of xtl.

The problem is that the second template parameter should be decltype(kth_container) as you can see from other examples of forward sequence. I should have changed that already, sorry.

Seems like I missed an instance of this, sorry (that's what you get for not having tests ;)

@khanley6 merged your PR and commits' are showing up here now :)

If it passes I consider it done!

Hey @khanley6 I am sorry, I messed something up with merging & rebasing, and only one of your commits is left in the history. Is it still OK for you if we merge like this (given the tests pass?)

Sure, no problem at all, merge ahead!

@JohanMabille I think tests shall pass now :) ready for review!


text:
Fire behaves wrongly

Fire can only be lit on the top faces of solid blocks, as opposed to being able to be lit on any face of a flammable block. Any pre-existing fire that isn't on the top face of a solid block will extinguish quickly.
Versions:
mc 1.19.3
ql 17.8, 18.1-beta.25
qfapi 5.0.0-alpha.5, 5.0.0-alpha.6
qsl 4.0.0-beta.2
fapi 0.68.1, 0.69.1

Oh, I almost forgot to mention: This was actually a QSL issue! And it was caused by 1.19.3 changes breaking how the capturing of vanilla flammables worked; This has been fixed since QSL 4.0.0-beta.3, which QFAPI 5.0.0-beta.6 includes

authors: EnnuiL hallamuck

repo: QuiltMC/quilted-fabric-api


text:
use Qwen2VLModel in huggingface got an unexpected keyword argument 'pixel_values'

from PIL import Image
import requests
from transformers import AutoProcessor, Qwen2VLModel

model = Qwen2VLModel.from_pretrained("Qwen/Qwen2-VL-2B-Instruct")
processor = AutoProcessor.from_pretrained("Qwen/Qwen2-VL-2B-Instruct")

url = "http://images.cocodataset.org/val2017/000000039769.jpg"
image = Image.open(requests.get(url, stream=True).raw)
inputs = processor(text=["a photo of a cat"], images=image, return_tensors="pt", padding=True)

outputs = model(**inputs)

TypeError: Qwen2VLModel.forward() got an unexpected keyword argument 'pixel_values'
I assume Qwen2VLModel should be used to get hidden states from text and image input, but looks like the normal pipeline fails

same as https://github.com/QwenLM/Qwen2-VL/issues/166


text:
Configuration

Hello!
Could you please add saving configuration button

I'm busy with other projects at the moment, but this is already in progress and will be in the next release.

This feature was added to version 1.2.10.

authors: R-Smith kadder

repo: R-Smith/vmPing


text:
Add option to delete modsettings to repair view

Modsettings has been merged into main of Northstar and will be released in the foreseeable future. This will cause conflicts in cases where users still have the old mod installed. As such an option to delete modsettings in repair view would be nice.

ModSettings has been marked deprecated for a while now so at this point this issue should be considered a duplicate of #368


text:
refactor: Store global const in separate file

Moved user agent there for now.
Storing all global consts in a single file makes adjusting them easier as one also have to look at a single place. This is especially useful for anyone wanting to make their own spin/fork of the application (NorthstarCN *hint* *hint* ;P)

Not at the moment but future PRs might of course make use of this ^^


text:
feat: Prevent reaper from replying to dev logs

1 line change, not much to say
This feature already existed but I guess how dev logs are marked within logs got changed?

Yup, dev logs are 0.0.0.X+dev where X is the CI build number as per https://github.com/R2Northstar/NorthstarLauncher/pull/541

authors: Bobbyperson GeckoEidechse


text:
Release a version that supports Swift 2.3

I have successfully built Rex with Swift 2.3 based on 6243fc56e02f8dad0cdbcfbb8ecdb8b5bf45c9f7.
Would it be possible to release a new version?

@RuiAAPeres?

@aschuch definitely. Sorry for the delay, I have been away from OS in general, I will take care of it.

@aschuch https://github.com/RACCommunity/Rex/releases/tag/0.12.0

@RuiAAPeres Awesome, thanks :)

authors: RuiAAPeres aschuch mdiep

repo: RACCommunity/Rex


text:
[FEAT] Add support for custom notification text and localisation

Is your feature request related to a problem? Please describe.

Tasks and notifications can be generated from the protocol, however, the notification title and body are currently hardcoded. It would be good to pull this from the protocol.
Localisation is also still not supported. In order to pull the correct notification text from the protocol, support for localisation (choosing the correct language text from the user's language) is required since the notification body is in the format:

"title": {
              "en": "Task time",
              "it": "E' il momento per un compito",
              "es": "Momento para la tarea",
              "nl": "Tijd voor een taak",
              "da": "Tid til at udføre opgaver",
              "de": "Zeit für Aufgaben"
            }

Describe the solution you'd like

The User class has the language property. This should be used to select the correct text from the notification block.
The NotificationHandler should have a case where it checks if notification text config is present in the protocol and falls back to the default text if it doesn't.

Priority
4
Difficulty
4

Solved in #458

repo: RADAR-base/RADAR-Appserver


text:
Python PIP package shouldn't install junk into /etc/ryu/faucet/

At the moment when you pip install ryu-faucet you get a lot of files in the config directory /etc/ryu/faucet/:

ubuntu@faucet:~/faucet$ ls /etc/ryu/faucet/
faucet_demo_step1.yaml  faucet_demo_step2.yaml  faucet_demo_step3.yaml  faucet_Lagopus.yaml  faucet_ovs.yaml  faucet.yaml  faucet_ZodiacFX.yaml  gauge.yaml

And unfortunately faucet.yaml and gauge.yaml are installed as data files (which means when you pip uninstall ryu-faucet these files will be deleted as well even if they have user changes).
I propose we install a /etc/ryu/faucet/faucet.yaml-dist and /etc/ryu/faucet/gauge.yaml-dist which are fully featured configuration examples which users can copy into the appropriate file names and make their changes so that PIP doesn't step on your toes and delete them.
Another solution may also be to flag them as configuration files that PIP will assume that user changes will be made to these files and it won't delete them. I know you can do that with DEB files but I'm not familiar enough with PIP to know if the same concept exists?

I have the /etc/ryu/faucet/*.yaml files as they also correspond to the
tutorial and demos that we have featured.  It is very useful for folks
getting started with Faucet.
Alternatively, we could build the *-dist.yaml file with all the comments
that one could use.
In regards to your question on flagging them as config files, I will check
on the same.
On Tue, Jan 3, 2017 at 5:20 PM, Brad Cowie notifications@github.com wrote:

At the moment when you pip install ryu-faucet you get a lot of files in
the config directory /etc/ryu/faucet/:
ubuntu@faucet:~/faucet$ ls /etc/ryu/faucet/
faucet_demo_step1.yaml faucet_demo_step2.yaml faucet_demo_step3.yaml
faucet_Lagopus.yaml faucet_ovs.yaml faucet.yaml faucet_ZodiacFX.yaml
gauge.yaml
And unfortunately faucet.yaml and gauge.yaml are installed as data files
(which means when you pip uninstall ryu-faucet these files will be deleted
as well even if they have user changes).
I propose we install a /etc/ryu/faucet/faucet.yaml-dist and
/etc/ryu/faucet/gauge.yaml-dist which are fully featured configuration
examples which users can copy into the appropriate file names and make
their changes so that PIP doesn't step on your toes and delete them.
Another solution may also be to flag them as configuration files that PIP
will assume that user changes will be made to these files and it won't
delete them. I know you can do that with DEB files but I'm not familiar
enough with PIP to know if the same concept exists?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/337, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABmf86s7p-vxccc5hT8bIQwo-36lEKcHks5rOvPegaJpZM4LaM9S
.

I understand why the separate files exist, I don't fully understand why they need to all be installed.
Currently there is no way to delete those files (they will be reinstalled when you PIP install --upgrade ryu_faucet).
Some people like their configuration directories to be clean and tidy :)

So how other projects handle this typically:

We could have an /etc/ryu/faucet/examples/ directory where these files are housed
We could install a /usr/share/doc/ryu/faucet/examples/ (or similar) directory where these files are housed

I like the examples directory idea.  If you are going to git move the
files, I will sync the repo and update the pip packaging for the same
accordingly.
On Tue, Jan 3, 2017 at 5:47 PM, Brad Cowie notifications@github.com wrote:

So how other projects handle this typically:

We could have an /etc/ryu/faucet/examples/ directory where these
files are housed
We could install a /usr/share/doc/ryu/faucet/examples/ (or similar)
directory where these files are housed

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/337#issuecomment-270275741, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABmf88yY3Lzb93A3nFNjmvMvkdwMMNhHks5rOvoWgaJpZM4LaM9S
.

Can we do a YAML scheme for faucet.yaml and this will enable us/users to
generate the yaml files lot more easily?  Maybe this can eliminate the
example files so that we can just change the schema and generate files.
On Tue, Jan 3, 2017 at 5:50 PM, Shivaram Mysore shivaram.mysore@gmail.com
wrote:

I like the examples directory idea.  If you are going to git move the
files, I will sync the repo and update the pip packaging for the same
accordingly.
On Tue, Jan 3, 2017 at 5:47 PM, Brad Cowie notifications@github.com
wrote:

So how other projects handle this typically:

We could have an /etc/ryu/faucet/examples/ directory where these
files are housed
We could install a /usr/share/doc/ryu/faucet/examples/ (or similar)
directory where these files are housed

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/337#issuecomment-270275741, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABmf88yY3Lzb93A3nFNjmvMvkdwMMNhHks5rOvoWgaJpZM4LaM9S
.

@shivarammysore check out PR#338 for review

authors: gizmoguy shivarammysore

repo: REANNZ/faucet


text:
Updated to include discussion items from the mailing list

https://list.waikato.ac.nz/pipermail/faucet-dev/2017-August/000253.html

Hi Shivaram,
I think including umbrella here without a link to the paper that describes the technique will cause some confusion here.
If you want, maybe throw up a github issue to describe what paragraphs you want added to the architecture document and I'll write them up this week?
I see the language is already a little clunky and ambiguous in the document so it probably requires a few fixups so it makes sense.
Thanks

Issue #866 created to track this.


text:
🛑 Cleanse Drops Kidney is down

In f63f4e5, Cleanse Drops Kidney (http://cleansedropskidney.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cleanse Drops Kidney is back up in ecc11f7 after 20 minutes.

repo: RJVCA/uptime


text:
🛑 Cleanse Drops Kidney is down

In 1de807d, Cleanse Drops Kidney (http://cleansedropskidney.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cleanse Drops Kidney is back up in 2946fdb after 16 minutes.


text:
🛑 Sensor Tracker login is down

In 1600c5c, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 720ce81 after 1 minute.

repo: RKTowse/upptime


text:
🛑 Sensor Tracker login is down

In 0ecff69, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in 6a6e8aa after 1 minute.


text:
🛑 CEOTR Home Page loads is down

In c6fcd4f, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 6ffb662.


text:
🛑 CEOTR Home Page loads is down

In ef790ca, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in e6752e0 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 30c6f2c, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 96fcb88 after 2 minutes.


text:
🛑 Sensor Tracker login is down

In a5eb4ec, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in d3e5941 after .


text:
🛑 CEOTR Home Page loads is down

In 9262101, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 2596ece.


text:
🛑 Sensor Tracker login is down

In 3a6f8b2, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sensor tracker login is back up in e22ada0.


text:
🛑 CEOTR Home Page loads is down

In e030402, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 3a225d7 after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 7ce7989, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in bc5729a.


text:
🛑 CEOTR Home Page loads is down

In 27b6d6b, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 532f8de.


text:
🛑 CEOTR Home Page loads is down

In ff5de8f, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 350d49c after 2 minutes.


text:
🛑 Sensor Tracker login is down

In 5665262, Sensor Tracker login (https://stg.ceotr.ca/sensor_tracker) was down:

HTTP code: 502
Response time: 43 ms

Resolved: Sensor tracker login is back up in c5ff3bf after 36 days, 0 hours, 34 minutes.


text:
🛑 RMUG Installations is down

In 34d2bb4, RMUG Installations (https://installations.rmusergroup.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RMUG Installations is back up in 5c586fe after 14 minutes.

repo: RM-User-Group/RMUG-Upptime


text:
Runner/Lurker Parity: You can take actions while you Leap self-stunned

Description
The "stun" we have on Runner/Lurker leap hits are meant to be a Root, not a Stun. You can hit, shove, or start grabs while Rooted. You just can not move.
Videos
https://github.com/user-attachments/assets/213cc551-f6aa-4728-8c3d-a2ab45d08f5d
https://github.com/user-attachments/assets/b428f224-8439-4122-9a61-25f622970ac9

would be ez to add, just add a movement modifier instead of stun

authors: Dutch-VanDerLinde Rainbeon


text:
libamdhip64.so.4 cause C++ vector assertion error

When I try to run a simple TF program, I get errors; FYI I get backtrace. TF 2.7.0 and rocm 4.5.0.
/usr/include/c++/11.1.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = hsa_signal_s; _Alloc = std::allocator<hsa_signal_s>; std::vector<_Tp, _Alloc>::reference = hsa_signal_s&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.

Thread 1 "python" received signal SIGABRT, Aborted.
0x00007ffff7a61d22 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7a61d22 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff7a4b862 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff5db9a1a in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#3  0x00007ffff5fc41e0 in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#4  0x00007ffff5fc680a in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#5  0x00007ffff5fc6cfa in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#6  0x00007ffff5f8a8d0 in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#7  0x00007ffff5f52618 in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#8  0x00007ffff5e3955b in ?? () from /opt/rocm/hip/lib/libamdhip64.so.4
#9  0x00007ffff5e5d5d2 in hipMemcpyHtoDAsync () from /opt/rocm/hip/lib/libamdhip64.so.4
#10 0x00007fffe8edc768 in stream_executor::gpu::GpuDriver::AsynchronousMemcpyH2D(stream_executor::gpu::GpuContext*, void*, void const*, unsigned long, ihipStream_t*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#11 0x00007fffe8c59644 in stream_executor::Stream::ThenMemcpy(stream_executor::DeviceMemoryBase*, void const*, unsigned long) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#12 0x00007fffd2866751 in tensorflow::GPUUtil::CopyCPUTensorToGPU(tensorflow::Tensor const*, tensorflow::DeviceContext const*, tensorflow::Device*, tensorflow::Tensor*, std::function<void (tensorflow::Status const&)>, bool) () from /usr/lib/python3.9/site-packages/tensorflow/python/../libtensorflow_framework.so.2
#13 0x00007fffd2868a23 in tensorflow::GPUDeviceContext::CopyCPUTensorToDevice(tensorflow::Tensor const*, tensorflow::Device*, tensorflow::Tensor*, std::function<void (tensorflow::Status const&)>, bool) const () from /usr/lib/python3.9/site-packages/tensorflow/python/../libtensorflow_framework.so.2
#14 0x00007fffd2984c19 in ?? () from /usr/lib/python3.9/site-packages/tensorflow/python/../libtensorflow_framework.so.2
#15 0x00007fffd2987a04 in tensorflow::CopyTensor::ViaDMA(absl::lts_20210324::string_view, tensorflow::DeviceContext*, tensorflow::DeviceContext*, tensorflow::Device*, tensorflow::Device*, tensorflow::AllocatorAttributes, tensorflow::AllocatorAttributes, tensorflow::Tensor const*, tensorflow::Tensor*, int, std::function<void (tensorflow::Status const&)>, bool) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/../libtensorflow_framework.so.2
#16 0x00007fffe41c94b8 in tensorflow::TensorHandle::CopyToDevice(tensorflow::EagerContext const&, tensorflow::Device*, tensorflow::Tensor*) const ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#17 0x00007fffdd9db369 in tensorflow::CopyToDeviceNode::Run() () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#18 0x00007fffe46b57d0 in tensorflow::EagerExecutor::SyncExecute(tensorflow::EagerNode*) () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#19 0x00007fffdd9dc91c in tensorflow::EagerCopyToDevice(tensorflow::TensorHandle*, tensorflow::EagerContext*, tensorflow::EagerExecutor*, tensorflow::Device*, bool, tensorflow::TensorHandle**) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#20 0x00007fffdd9e1d2c in ?? () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#21 0x00007fffdd9e2aac in ?? () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#22 0x00007fffdd9eb51c in ?? () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#23 0x00007fffdd9ec6e0 in tensorflow::EagerExecute(tensorflow::EagerOperation*, tensorflow::TensorHandle**, int*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#24 0x00007fffdd78fa7b in tensorflow::EagerOperation::Execute(absl::lts_20210324::Span<tensorflow::AbstractTensorHandle*>, int*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#25 0x00007fffe41f30f9 in tensorflow::CustomDeviceOpHandler::Execute(tensorflow::ImmediateExecutionOperation*, tensorflow::ImmediateExecutionTensorHandle**, int*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#26 0x00007fffdd33e126 in TFE_Execute () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#27 0x00007fffdd29b733 in tensorflow::EagerConst(TFE_Context*, TFE_TensorHandle*, char const*, TF_Status*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#28 0x00007fffdd29d3fc in tensorflow::ConvertToEagerTensorUncached(TFE_Context*, _object*, tensorflow::DataType, char const*) ()
   from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#29 0x00007fffdd29e688 in EagerTensor_init () from /usr/lib/python3.9/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#30 0x00007ffff7d220cb in _PyObject_MakeTpCall () from /usr/lib/libpython3.9.so.1.0
#31 0x00007ffff7d1e13b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#32 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#33 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#34 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#35 0x00007ffff7d296eb in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#36 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
--Type <RET> for more, q to quit, c to continue without paging--
#37 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#38 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#39 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#40 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#41 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#42 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#43 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#44 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#45 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#46 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#47 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#48 0x00007ffff7d38c49 in PyObject_Call () from /usr/lib/libpython3.9.so.1.0
#49 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#50 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#51 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#52 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#53 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#54 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#55 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#56 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#57 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#58 0x00007ffff7d38c49 in PyObject_Call () from /usr/lib/libpython3.9.so.1.0
#59 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#60 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#61 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#62 0x00007ffff7d38c49 in PyObject_Call () from /usr/lib/libpython3.9.so.1.0
#63 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#64 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#65 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#66 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#67 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#68 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#69 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#70 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#71 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#72 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#73 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#74 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#75 0x00007ffff7d1db89 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#76 0x00007ffff7d296eb in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#77 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#78 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#79 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#80 0x00007ffff7d3517e in ?? () from /usr/lib/libpython3.9.so.1.0
#81 0x00007ffff7d220cb in _PyObject_MakeTpCall () from /usr/lib/libpython3.9.so.1.0
#82 0x00007ffff7d1e2a5 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#83 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#84 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#85 0x00007ffff7d3517e in ?? () from /usr/lib/libpython3.9.so.1.0
#86 0x00007ffff7d2254b in ?? () from /usr/lib/libpython3.9.so.1.0
--Type <RET> for more, q to quit, c to continue without paging--
#87 0x00007ffff7d38d02 in PyObject_Call () from /usr/lib/libpython3.9.so.1.0
#88 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#89 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#90 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#91 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#92 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#93 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#94 0x00007ffff7d38c49 in PyObject_Call () from /usr/lib/libpython3.9.so.1.0
#95 0x00007ffff7d1bc6b in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#96 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#97 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#98 0x00007ffff7d385d4 in ?? () from /usr/lib/libpython3.9.so.1.0
#99 0x00007ffff7d1a18f in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#100 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#101 0x00007ffff7d17c41 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.9.so.1.0
#102 0x00007ffff7dcf633 in PyEval_EvalCode () from /usr/lib/libpython3.9.so.1.0
#103 0x00007ffff7dd664c in ?? () from /usr/lib/libpython3.9.so.1.0
#104 0x00007ffff7d2a198 in ?? () from /usr/lib/libpython3.9.so.1.0
#105 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#106 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#107 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#108 0x00007ffff7d19376 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.9.so.1.0
#109 0x00007ffff7d17fd9 in ?? () from /usr/lib/libpython3.9.so.1.0
#110 0x00007ffff7d2990e in _PyFunction_Vectorcall () from /usr/lib/libpython3.9.so.1.0
#111 0x00007ffff7dfa3c8 in ?? () from /usr/lib/libpython3.9.so.1.0
#112 0x00007ffff7df0cb4 in Py_RunMain () from /usr/lib/libpython3.9.so.1.0
#113 0x00007ffff7dc1ab9 in Py_BytesMain () from /usr/lib/libpython3.9.so.1.0
#114 0x00007ffff7a4cb25 in __libc_start_main () from /usr/lib/libc.so.6
#115 0x000055555555504e in _start ()

Thank you for reporting the issue, it will be fixed. Basically for some reason your build  enabled _GLIBCXX_ASSERTIONS and by default it's disabled in our environment.

@gandryey Thank you for the quick reply - is there some quick fix I can try?

Sure, if you rebuild runtime.
In hsaCopy() and copyBufferRect() under rocblit.cpp, there are calls of hsa_amd_memory_async_copy().
Replace the argument &wait_events[0] with "(wait_events.size() > 0) ? &wait_events[0] : nullptr"
Basically if wait_events.size() is 0, then the list is ignored, but the validation check could trigger abort.

Where can I find the file? Also, is there some cmake argument I can pass to disable this out-of-bound check (since that would easier)?
Currently my build looks like this
build() {
  mkdir build && cd build
  cmake -Wno-dev \
  -S "$srcdir/$_dirhipamd" \
  -DHIP_COMMON_DIR="$srcdir/$_dirhip" \
  -DAMD_OPENCL_PATH="$srcdir/$_diropencl" \
  -DROCCLR_PATH="$srcdir/$_dirrocclr" \
  -DHIP_PLATFORM=amd \
  -DCMAKE_INSTALL_PREFIX=/opt/rocm/hip

  make
}

Try to remove -Wno-dev and add explicit release build with -DCMAKE_BUILD_TYPE=Release. However I don't really know what exactly triggered  _GLIBCXX_ASSERTIONS in your build. Maybe some global setting in the compiler on your system, because even for debug build our cmake doesn't enable that define. LLVM cmake may declare that define for debug purposes.

@gandryey thank you - I think patching the source code would just be easier. I will post the patch when I get time to do it.

Actually instead of that condition you can use just wait_events.data(). That will produce a bit more optimal code.

@gandryey Thank you - I tried your first suggestion anyway and it works. Here is the patch:
--- ROCclr-rocm-4.5.0/device/rocm/rocblit.cpp	2021-11-25 22:38:12.837707706 +0100
+++ ROCclr-rocm-4.5.0/device/rocm/rocblit.cpp	2021-11-25 22:40:00.699796341 +0100
@@ -460,7 +460,7 @@
               std::this_thread::get_id(), (wait_events.size() != 0) ? wait_events[0].handle : 0,
               active.handle);
       hsa_status_t status = hsa_amd_memory_async_copy_rect(&dstMem, &offset,
-          &srcMem, &offset, &dim, agent, direction, wait_events.size(), &wait_events[0], active);
+          &srcMem, &offset, &dim, agent, direction, wait_events.size(), (wait_events.size() > 0) ? &wait_events[0] : nullptr, active);
       if (status != HSA_STATUS_SUCCESS) {
         gpu().Barriers().ResetCurrentSignal();
         LogPrintfError("DMA buffer failed with code %d", status);
@@ -484,7 +484,7 @@
           hsa_status_t status = hsa_amd_memory_async_copy(
               (reinterpret_cast<address>(dst) + dstOffset), dstAgent,
               (reinterpret_cast<const_address>(src) + srcOffset), srcAgent,
-              size[0], wait_events.size(), &wait_events[0], active);
+              size[0], wait_events.size(), (wait_events.size() > 0) ? &wait_events[0] : nullptr, active);
           if (status != HSA_STATUS_SUCCESS) {
             gpu().Barriers().ResetCurrentSignal();
             LogPrintfError("DMA buffer failed with code %d", status);
@@ -671,7 +671,7 @@
           active.handle);

   status = hsa_amd_memory_async_copy(dst, dstAgent, src, srcAgent,
-      size[0], wait_events.size(), &wait_events[0], active);
+      size[0], wait_events.size(), (wait_events.size() > 0) ? &wait_events[0] : nullptr, active);
   if (status == HSA_STATUS_SUCCESS) {
     gpu().addSystemScope();
   } else {

With  wait_events.data() the generated CPU code is simpler and will be inline.
hsa_amd_memory_async_copy/hsa_amd_memory_async_copy_rect() ignores the argument if size is 0.

@param[in] dep_signals List of signals that must be waited on before the copy
operation starts. The copy will start after every signal has been observed with
the value 0. The dependent signal should not include completion signal from hsa_amd_memory_async_copy
operation to be issued in future as that can result in a deadlock. **If @p num_dep_signals is 0, this
argument is ignored.**
https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/fc99cf8516ef4bfc6311471b717838604a673b73/src/inc/hsa_ext_amd.h#L1121

Thank you - that's more elaboration than I asked. :smile:  I will update the patch tomorrow.

Looks fine.

authors: gandryey riaqn

repo: ROCm-Developer-Tools/HIP


text:
[RUN] Allow custom babelstream array size

This patch allows to specify the number of elements in the babelstream arrays used to determine bandwidth. The number is multiplied by 1024 to fullfil the HIP requirement of the sizes being multiples of 1024.

If no custom size is given, the behavior is unchanged.

repo: ROCm-Developer-Tools/aomp


text:
Bug in hipMemset

The following code
https://github.com/ROCm-Developer-Tools/HIP/blob/master/src/hip_memory.cpp#L1854-L1860
is incorrect.
Suppose it is called with a pointer dst=0x01, type char, count 64.
Then aligned_dst is 0x04, n_head is 3, n=(64-3)/4=15, n_tail=0. Then handleHeadTail (line 1827) sets locations 0x01, 0x02, 0x03, and hsa_amd_memory_fill (line 1899) sets locations 0x4 through 0x3f. Location 0x40 is left unchanged. This is wrong.
Additionally, even if you correctly calculate n_tail as 1, it still won't work. Because, at line 1827, thread 0 sets 0x01, thread 1 sets 0x02, thread 2 sets 0x03, and thread 3 sets 0x01+(3-3+15*4)=0x3D instead of 0x40. Line 1827 should read
                p[(threadIdx.x < nh) ? threadIdx.x : (threadIdx.x + nb)] = x;

Closing the ticket as issue has been fixed.

repo: ROCm/HIP


text:
MaxWavesPerSimd in ihipOccupancyMaxActiveBlocksPerMultiprocessor() is not consistent with rocminfo

Here, the MaxWavesPerSimd is set to 8.
https://github.com/ROCm-Developer-Tools/HIP/blob/bc102bb6dbbc7b94218a73e14f6ca9de198069e9/rocclr/hip_platform.cpp#L323
But in rocminfo:
*******
Agent 2
*******
  Name:                    gfx906
  Uuid:                    GPU-19a8190172e626c2
  Marketing Name:          Vega 20
  Vendor Name:             AMD
  Feature:                 KERNEL_DISPATCH
  Profile:                 BASE_PROFILE
  Float Round Mode:        NEAR
  Max Queue Number:        128(0x80)
  Queue Min Size:          4096(0x1000)
  Queue Max Size:          131072(0x20000)
  Queue Type:              MULTI
  Node:                    1
  Device Type:             GPU
  Cache Info:
    L1:                      16(0x10) KB
  Chip ID:                 26273(0x66a1)
  Cacheline Size:          64(0x40)
  Max Clock Freq. (MHz):   1725
  BDFID:                   768
  Internal Node ID:        1
  Compute Unit:            60
  SIMDs per CU:            4
  Shader Engines:          4
  Shader Arrs. per Eng.:   1
  WatchPts on Addr. Ranges:4
  Features:                KERNEL_DISPATCH
  Fast F16 Operation:      FALSE
  Wavefront Size:          64(0x40)
  Workgroup Max Size:      1024(0x400)
  Workgroup Max Size per Dimension:
    x                        1024(0x400)
    y                        1024(0x400)
    z                        1024(0x400)
  Max Waves Per CU:        40(0x28)
  Max Work-item Per CU:    2560(0xa00)
  Grid Max Size:           4294967295(0xffffffff)
  Grid Max Size per Dimension:
    x                        4294967295(0xffffffff)
    y                        4294967295(0xffffffff)
    z                        4294967295(0xffffffff)
  Max fbarriers/Workgrp:   32
  Pool Info:
    Pool 1
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED
      Size:                    16760832(0xffc000) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Alignment:         4KB
      Accessible by all:       FALSE
    Pool 2
      Segment:                 GROUP
      Size:                    64(0x40) KB
      Allocatable:             FALSE
      Alloc Granule:           0KB
      Alloc Alignment:         0KB
      Accessible by all:       FALSE
  ISA Info:
    ISA 1
      Name:                    amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-
      Machine Models:          HSA_MACHINE_MODEL_LARGE
      Profiles:                HSA_PROFILE_BASE
      Default Rounding Mode:   NEAR
      Default Rounding Mode:   NEAR
      Fast f16:                TRUE
      Workgroup Max Size:      1024(0x400)
      Workgroup Max Size per Dimension:
        x                        1024(0x400)
        y                        1024(0x400)
        z                        1024(0x400)
      Grid Max Size:           4294967295(0xffffffff)
      Grid Max Size per Dimension:
        x                        4294967295(0xffffffff)
        y                        4294967295(0xffffffff)
        z                        4294967295(0xffffffff)
      FBarrier Max Size:       32
*** Done ***

 SIMDs per CU is 4  and Max Waves Per CU is 40, which means MaxWavesPerSimd should be 10?
Which one is right?

@francis0407, Sorry for the lack of response. Do you still need assistance with this issue?


text:
Fix wmma api parity

hipify the wmma api call with rocwmma

Hello, I am sorry to disturb you but I cannot find any place I can report an issue related to this library. I am testing the new MI300X machine and having trouble importing bitsandbytes after successful installation. I am unsure if I can disclose the error message here, so I am waiting for a response from any developers on the AMD's side. Please reach out to me through seungduk.kim@yanolja.com I am a software engineer and I can explain what I am experiencing now. Thanks!

Hi @seungduk-yanolja , please try installing it from rocm_enabled branch, the instructions are on that page, please be aware that full enablement is still pending. You can report any future issues on https://github.com/ROCm/rocm repo.

Hello, I am sorry to disturb you but I cannot find any place I can report an issue related to this library. I am testing the new MI300X machine and having trouble importing bitsandbytes after successful installation. I am unsure if I can disclose the error message here, so I am waiting for a response from any developers on the AMD's side. Please reach out to me through seungduk.kim@yanolja.com I am a software engineer and I can explain what I am experiencing now. Thanks!

Hi @seungduk-yanolja , please try installing it from rocm_enabled branch, the instructions are on that page, please be aware that full enablement is still pending. You can report any future issues on https://github.com/ROCm/rocm repo.

Hi @pnunna93, yes, I installed it from the rocm_enabled branch because I saw PRs were merged into this branch.
ChatGPT said this
The backtrace provided indicates that the core dump resulted from a segmentation fault (SIGABRT) triggered within the Python process. Specifically, the crash occurs during the dynamic loading of a shared library related to the torch package, more precisely within libhipblaslt.so, which is part of the ROCm platform for AMD GPUs. This suggests an issue related to the HIP/ROCm ecosystem, possibly due to an incompatibility or a bug in the library or its dependencies.
The key points in the backtrace indicating the source of the issue are:

The termination happens after an attempt to load ExtOpMasterLibrary from libhipblaslt.so, which is part of the ROCm software stack.
The crash is preceded by a std::runtime_error, indicating that an exception was thrown within the C++ standard library, leading to a call to std::terminate(), which then causes the process to abort.

Given the complexity of debugging segmentation faults in dynamically loaded libraries, especially within the context of GPU computing, resolving such issues can sometimes require deep technical knowledge of the libraries and the underlying hardware. Collaboration with the community or seeking support from the developers of the libraries involved may be necessary.

Hello, I am sorry to disturb you but I cannot find any place I can report an issue related to this library. I am testing the new MI300X machine and having trouble importing bitsandbytes after successful installation. I am unsure if I can disclose the error message here, so I am waiting for a response from any developers on the AMD's side. Please reach out to me through seungduk.kim@yanolja.com I am a software engineer and I can explain what I am experiencing now. Thanks!

Hi @seungduk-yanolja , please try installing it from rocm_enabled branch, the instructions are on that page, please be aware that full enablement is still pending. You can report any future issues on https://github.com/ROCm/rocm repo.

Reported the issue here: ROCm/ROCm#2885
Hi @pnunna93, yes, I installed it from the rocm_enabled branch because I saw PRs were merged into this branch. ChatGPT said this:
The backtrace provided indicates that the core dump resulted from a segmentation fault (SIGABRT) triggered within the Python process. Specifically, the crash occurs during the dynamic loading of a shared library related to the torch package, more precisely within libhipblaslt.so, which is part of the ROCm platform for AMD GPUs. This suggests an issue related to the HIP/ROCm ecosystem, possibly due to an incompatibility or a bug in the library or its dependencies.
The key points in the backtrace indicating the source of the issue are:

The termination happens after an attempt to load ExtOpMasterLibrary from libhipblaslt.so, which is part of the ROCm software stack.
The crash is preceded by a std::runtime_error, indicating that an exception was thrown within the C++ standard library, leading to a call to std::terminate(), which then causes the process to abort.

Given the complexity of debugging segmentation faults in dynamically loaded libraries, especially within the context of GPU computing, resolving such issues can sometimes require deep technical knowledge of the libraries and the underlying hardware. Collaboration with the community or seeking support from the developers of the libraries involved may be necessary.

Hi @seungduk-yanolja , please reinstall hipblaslt with these steps:
git clone --recurse https://github.com/ROCmSoftwarePlatform/hipBLASLt
cd hipBLASLt
git checkout 4b3b34405e7e25cff404f69bfd0a832644430477
./install.sh -idc
You may need to copy and relink hipblaslt .so files from build dir to /opt/rocm/lib/ if it doesn't automatically get replaced after build.

Hello, I am sorry to disturb you but I cannot find any place I can report an issue related to this library. I am testing the new MI300X machine and having trouble importing bitsandbytes after successful installation. I am unsure if I can disclose the error message here, so I am waiting for a response from any developers on the AMD's side. Please reach out to me through seungduk.kim@yanolja.com I am a software engineer and I can explain what I am experiencing now. Thanks!

Hi @seungduk-yanolja , please try installing it from rocm_enabled branch, the instructions are on that page, please be aware that full enablement is still pending. You can report any future issues on https://github.com/ROCm/rocm repo.

Reported the issue here: ROCm/ROCm#2885
Hi @pnunna93, yes, I installed it from the rocm_enabled branch because I saw PRs were merged into this branch. ChatGPT said this:
The backtrace provided indicates that the core dump resulted from a segmentation fault (SIGABRT) triggered within the Python process. Specifically, the crash occurs during the dynamic loading of a shared library related to the torch package, more precisely within libhipblaslt.so, which is part of the ROCm platform for AMD GPUs. This suggests an issue related to the HIP/ROCm ecosystem, possibly due to an incompatibility or a bug in the library or its dependencies.
The key points in the backtrace indicating the source of the issue are:

The termination happens after an attempt to load ExtOpMasterLibrary from libhipblaslt.so, which is part of the ROCm software stack.
The crash is preceded by a std::runtime_error, indicating that an exception was thrown within the C++ standard library, leading to a call to std::terminate(), which then causes the process to abort.

Given the complexity of debugging segmentation faults in dynamically loaded libraries, especially within the context of GPU computing, resolving such issues can sometimes require deep technical knowledge of the libraries and the underlying hardware. Collaboration with the community or seeking support from the developers of the libraries involved may be necessary.

Hi @seungduk-yanolja , please reinstall hipblaslt with these steps: git clone --recurse https://github.com/ROCmSoftwarePlatform/hipBLASLt cd hipBLASLt git checkout 4b3b34405e7e25cff404f69bfd0a832644430477 ./install.sh -idc
You may need to copy and relink hipblaslt .so files from build dir to /opt/rocm/lib/ if it doesn't automatically get replaced after build.

It looks like the same command lines as described in the README.md of rocm_enabled branch. I used these but let me retry.

Hey all! I'm Titus, one of the bitsandbytes maintainers. We currently have a strong push underway to officially make different hardware backends than CUDA possible in BNB. Would you be willing to help us to get the AMD part right and consolidate the code-bases?

Hey all! I'm Titus, one of the bitsandbytes maintainers. We currently have a strong push underway to officially make different hardware backends than CUDA possible in BNB. Would you be willing to help us to get the AMD part right and consolidate the code-bases?

Hi @Titus-von-Koeller , sure! we were planning to reach out to you once we closed some internal dependencies.  Is there a forum we can discuss ?

It looks like the same command lines as described in the README.md of rocm_enabled branch. I used these but let me retry.
Update: I tried to install hipBLASLt again but there was an error (invalid memory access) and the whole filesystem became read-only. I rebooted the machine and then it did not correctly recognize the GPUs. I rebooted the IPMI and then it became normal. At this moment, what I can do with this machine (MI300X) is run vLLM with 4 out of 8 GPUs because the output became so weird when I used all 8 GPUs. Will try and explore more what I can do.

Hi @seungduk-yanolja, sounds like there is an issue with hipblaslt build/linking. The version I pointed to has ExtOpMasterLibrary class but something else is going wrong in the build. Please check back on the ROCm issue, they would be able to help. Thanks.

Thank you all. I do not have access to the machine anymore since it was a short-time PoC. There is another PoC is scheduled so will try again. Thanks again.

repo: ROCm/bitsandbytes


text:
test.so build faled

2023-09-17 19:02:48,710 INFO <aitemplate.backend.codegen> generated 207 function srcs
2023-09-17 19:02:50,015 INFO <aitemplate.backend.codegen> generated 8 library srcs
2023-09-17 19:02:50,015 INFO <aitemplate.backend.builder> Using 16 CPU for building
2023-09-17 19:07:31,399 INFO <aitemplate.compiler.compiler> compiled the final .so file elapsed time: 0:04:41.384353
[19:07:31] model_container.cpp:67: Device Runtime Version: 50422803; Driver Version: 50422803
[19:07:31] model_container.cpp:81: Hardware accelerator device properties:
Device:
ASCII string identifying device: AMD Radeon RX 6750 XT
Major compute capability: 10
Minor compute capability: 3
AMD GCN Arch Value: 1030
PCI bus ID of the device: 3
PCI device ID of the device: 0
Memory limits:
Constant memory available on device in bytes: 2147483647
Global memory available on device in bytes: 12868124672
Global memory bus width in bits: 192
Size of L2 cache in bytes: 3145728
Shared memory available per block in bytes: 65536
Maximum Shared Memory Per Multiprocessor in bytes: 65536
[19:07:31] model_container.cpp:85: Init AITemplate Runtime with 1 concurrency
Traceback (most recent call last):
File "/home/beforespace/AITnew/AITemplate/examples/05_stable_diffusion/scripts/compile.py", line 106, in
compile_diffusers()
File "/home/beforespace/AITnew/AITemplate/venv/lib/python3.10/site-packages/click/core.py", line 1157, in call
return self.main(*args, **kwargs)
File "/home/beforespace/AITnew/AITemplate/venv/lib/python3.10/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
File "/home/beforespace/AITnew/AITemplate/venv/lib/python3.10/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/beforespace/AITnew/AITemplate/venv/lib/python3.10/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "/home/beforespace/AITnew/AITemplate/examples/05_stable_diffusion/scripts/compile.py", line 95, in compile_diffusers
compile_vae(
File "/home/beforespace/AITnew/AITemplate/examples/05_stable_diffusion/src/compile_lib/compile_vae.py", line 128, in compile_vae
params_ait = map_vae_params(ait_vae, pt_mod, batch_size, height * width)
File "/home/beforespace/AITnew/AITemplate/examples/05_stable_diffusion/src/compile_lib/compile_vae.py", line 48, in map_vae_params
q_weight = pt_params[prefix + "query.weight"]
KeyError: 'decoder.mid_block.attentions.0.query.weight'

use special version of diffusers and transformers,in 05 stable diffusion 's readme.md

repo: ROCmSoftwarePlatform/AITemplate


text:
Support for NHWC format type in Miopen Convolution

Does MIOpen support convolution with following combination?
Src =  NHWC
Weights =  NHWC
Dst =  NHWC
and whatever the datatype is (whether f32, f16, s8).

Yes. What is the issue?

Thanks for your reply. I just wanted to confirm whether it supports or not. I'm referring to this documentation to find the supported format tags, but I was unable to find. That's why I raised this question.
If possible, could you please provide any other relevant links?

No links, sorry. We'll update the docs.

[Attribution] @junliume @johnny-keker https://github.com/ROCmSoftwarePlatform/MIOpen/labels/documentation https://github.com/ROCmSoftwarePlatform/MIOpen/labels/enhancement https://github.com/ROCmSoftwarePlatform/MIOpen/labels/urgency_normal No ideas about assignee.

@junliume @atamazov Internal ticket is created to fix docs. Thanks!

@ppanchad-amd I guess we can close this one then. Thanks.

authors: AryanKarumuri atamazov ppanchad-amd

repo: ROCmSoftwarePlatform/MIOpen