text:
CenterNet can't be trained

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
I have read the FAQ documentation but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
A clear and concise description of what the bug is:
I use mmdetection to train my own dataset, CenterNet can't be trained while Faster RCNN is ok. The type of dataset is Coco,  the number of labels is 6（except background）.
Reproduction

What command or script did you run?

python tools/train.py configs/centernet/centernet_resnet18_140e_coco.py

Did you make any modifications on the code or config? Did you understand what you have modified?
Only the classnames.
What dataset did you use?
My own dataset. The type of dataset is Coco,  the number of labels is 6（except background）. labels are chinses. The file structure of the dataset is as follows：
--data
------coco
--------annotations
------------instances_test2017.json
------------instances_val2017.json
------------instances_train2017.json
--------test2017
--------val2017
--------train2017

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment information and paste it here.
sys.platform: linux
Python: 3.6.12 |Anaconda, Inc.| (default, Sep  8 2020, 23:10:56) [GCC 7.3.0]
CUDA available: True
GPU 0: Tesla V100-PCIE-32GB
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 10.1, V10.1.243
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.6.0+cu101
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) Math Kernel Library Version 2019.0.5 Product Build 20190808 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.5.0 (Git Hash e2ac1fac44c5078ca927cb9b90e1b3066a0b2ed0)
OpenMP 201511 (a.k.a. OpenMP 4.5)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 10.1
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75
CuDNN 7.6.3
Magma 2.5.2
Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DUSE_VULKAN_WRAPPER -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON, USE_STATIC_DISPATCH=OFF,

TorchVision: 0.7.0+cu101
OpenCV: 4.5.4-dev
MMCV: 1.3.15
MMCV Compiler: GCC 7.5
MMCV CUDA Compiler: 10.1
MMDetection: 2.17.0+9874180

You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
pip install pytorch
2021-10-28 15:19:56,524 - mmdet - INFO - Environment info:
------------------------------------------------------------
sys.platform: linux
Python: 3.6.12 |Anaconda, Inc.| (default, Sep  8 2020, 23:10:56) [GCC 7.3.0]
CUDA available: True
GPU 0: Tesla V100-PCIE-32GB
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 10.1, V10.1.243
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.6.0+cu101
PyTorch compiling details: PyTorch built with:
  - GCC 7.3
  - C++ Version: 201402
  - Intel(R) Math Kernel Library Version 2019.0.5 Product Build 20190808 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v1.5.0 (Git Hash e2ac1fac44c5078ca927cb9b90e1b3066a0b2ed0)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - NNPACK is enabled
  - CPU capability usage: AVX2
  - CUDA Runtime 10.1
  - NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75
  - CuDNN 7.6.3
  - Magma 2.5.2
  - Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DUSE_VULKAN_WRAPPER -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON, USE_STATIC_DISPATCH=OFF,

TorchVision: 0.7.0+cu101
OpenCV: 4.5.4-dev
MMCV: 1.3.15
MMCV Compiler: GCC 7.5
MMCV CUDA Compiler: 10.1
MMDetection: 2.17.0+9874180
------------------------------------------------------------

2021-10-28 15:19:56,981 - mmdet - INFO - Distributed training: False
2021-10-28 15:19:57,393 - mmdet - INFO - Config:
dataset_type = 'CocoDataset'
data_root = 'data/coco/'
img_norm_cfg = dict(
    mean=[123.675, 116.28, 103.53], std=[58.395, 57.12, 57.375], to_rgb=True)
train_pipeline = [
    dict(type='LoadImageFromFile', to_float32=True, color_type='color'),
    dict(type='LoadAnnotations', with_bbox=True),
    dict(
        type='PhotoMetricDistortion',
        brightness_delta=32,
        contrast_range=(0.5, 1.5),
        saturation_range=(0.5, 1.5),
        hue_delta=18),
    dict(
        type='RandomCenterCropPad',
        crop_size=(512, 512),
        ratios=(0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3),
        mean=[0, 0, 0],
        std=[1, 1, 1],
        to_rgb=True,
        test_pad_mode=None),
    dict(type='Resize', img_scale=(512, 512), keep_ratio=True),
    dict(type='RandomFlip', flip_ratio=0.5),
    dict(
        type='Normalize',
        mean=[123.675, 116.28, 103.53],
        std=[58.395, 57.12, 57.375],
        to_rgb=True),
    dict(type='DefaultFormatBundle'),
    dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels'])
]
test_pipeline = [
    dict(type='LoadImageFromFile', to_float32=True),
    dict(
        type='MultiScaleFlipAug',
        scale_factor=1.0,
        flip=False,
        transforms=[
            dict(type='Resize', keep_ratio=True),
            dict(
                type='RandomCenterCropPad',
                ratios=None,
                border=None,
                mean=[0, 0, 0],
                std=[1, 1, 1],
                to_rgb=True,
                test_mode=True,
                test_pad_mode=['logical_or', 31],
                test_pad_add_pix=1),
            dict(type='RandomFlip'),
            dict(
                type='Normalize',
                mean=[123.675, 116.28, 103.53],
                std=[58.395, 57.12, 57.375],
                to_rgb=True),
            dict(type='DefaultFormatBundle'),
            dict(
                type='Collect',
                meta_keys=('filename', 'ori_shape', 'img_shape', 'pad_shape',
                           'scale_factor', 'flip', 'flip_direction',
                           'img_norm_cfg', 'border'),
                keys=['img'])
        ])
]
data = dict(
    samples_per_gpu=16,
    workers_per_gpu=4,
    train=dict(
        type='RepeatDataset',
        times=5,
        dataset=dict(
            type='CocoDataset',
            ann_file='data/coco/annotations/instances_train2017.json',
            img_prefix='data/coco/train2017/',
            pipeline=[
                dict(
                    type='LoadImageFromFile',
                    to_float32=True,
                    color_type='color'),
                dict(type='LoadAnnotations', with_bbox=True),
                dict(
                    type='PhotoMetricDistortion',
                    brightness_delta=32,
                    contrast_range=(0.5, 1.5),
                    saturation_range=(0.5, 1.5),
                    hue_delta=18),
                dict(
                    type='RandomCenterCropPad',
                    crop_size=(512, 512),
                    ratios=(0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3),
                    mean=[0, 0, 0],
                    std=[1, 1, 1],
                    to_rgb=True,
                    test_pad_mode=None),
                dict(type='Resize', img_scale=(512, 512), keep_ratio=True),
                dict(type='RandomFlip', flip_ratio=0.5),
                dict(
                    type='Normalize',
                    mean=[123.675, 116.28, 103.53],
                    std=[58.395, 57.12, 57.375],
                    to_rgb=True),
                dict(type='DefaultFormatBundle'),
                dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels'])
            ])),
    val=dict(
        type='CocoDataset',
        ann_file='data/coco/annotations/instances_val2017.json',
        img_prefix='data/coco/val2017/',
        pipeline=[
            dict(type='LoadImageFromFile', to_float32=True),
            dict(
                type='MultiScaleFlipAug',
                scale_factor=1.0,
                flip=False,
                transforms=[
                    dict(type='Resize', keep_ratio=True),
                    dict(
                        type='RandomCenterCropPad',
                        ratios=None,
                        border=None,
                        mean=[0, 0, 0],
                        std=[1, 1, 1],
                        to_rgb=True,
                        test_mode=True,
                        test_pad_mode=['logical_or', 31],
                        test_pad_add_pix=1),
                    dict(type='RandomFlip'),
                    dict(
                        type='Normalize',
                        mean=[123.675, 116.28, 103.53],
                        std=[58.395, 57.12, 57.375],
                        to_rgb=True),
                    dict(type='DefaultFormatBundle'),
                    dict(
                        type='Collect',
                        meta_keys=('filename', 'ori_shape', 'img_shape',
                                   'pad_shape', 'scale_factor', 'flip',
                                   'flip_direction', 'img_norm_cfg', 'border'),
                        keys=['img'])
                ])
        ]),
    test=dict(
        type='CocoDataset',
        ann_file='data/coco/annotations/instances_test2017.json',
        img_prefix='data/coco/test2017/',
        pipeline=[
            dict(type='LoadImageFromFile', to_float32=True),
            dict(
                type='MultiScaleFlipAug',
                scale_factor=1.0,
                flip=False,
                transforms=[
                    dict(type='Resize', keep_ratio=True),
                    dict(
                        type='RandomCenterCropPad',
                        ratios=None,
                        border=None,
                        mean=[0, 0, 0],
                        std=[1, 1, 1],
                        to_rgb=True,
                        test_mode=True,
                        test_pad_mode=['logical_or', 31],
                        test_pad_add_pix=1),
                    dict(type='RandomFlip'),
                    dict(
                        type='Normalize',
                        mean=[123.675, 116.28, 103.53],
                        std=[58.395, 57.12, 57.375],
                        to_rgb=True),
                    dict(type='DefaultFormatBundle'),
                    dict(
                        type='Collect',
                        meta_keys=('filename', 'ori_shape', 'img_shape',
                                   'pad_shape', 'scale_factor', 'flip',
                                   'flip_direction', 'img_norm_cfg', 'border'),
                        keys=['img'])
                ])
        ]))
evaluation = dict(interval=1, metric='bbox')
optimizer = dict(type='SGD', lr=0.02, momentum=0.9, weight_decay=0.0001)
optimizer_config = dict(grad_clip=dict(max_norm=35, norm_type=2))
lr_config = dict(
    policy='step',
    warmup='linear',
    warmup_iters=1000,
    warmup_ratio=0.001,
    step=[18, 24])
runner = dict(type='EpochBasedRunner', max_epochs=28)
checkpoint_config = dict(interval=1)
log_config = dict(interval=50, hooks=[dict(type='TextLoggerHook')])
custom_hooks = [dict(type='NumClassCheckHook')]
dist_params = dict(backend='nccl')
log_level = 'INFO'
load_from = None
resume_from = None
workflow = [('train', 1)]
model = dict(
    type='CenterNet',
    backbone=dict(
        type='ResNet',
        depth=18,
        norm_eval=False,
        norm_cfg=dict(type='BN'),
        init_cfg=dict(type='Pretrained', checkpoint='torchvision://resnet18')),
    neck=dict(
        type='CTResNetNeck',
        in_channel=512,
        num_deconv_filters=(256, 128, 64),
        num_deconv_kernels=(4, 4, 4),
        use_dcn=False),
    bbox_head=dict(
        type='CenterNetHead',
        num_classes=6,
        in_channel=64,
        feat_channel=64,
        loss_center_heatmap=dict(type='GaussianFocalLoss', loss_weight=1.0),
        loss_wh=dict(type='L1Loss', loss_weight=0.1),
        loss_offset=dict(type='L1Loss', loss_weight=1.0)),
    train_cfg=None,
    test_cfg=dict(topk=100, local_maximum_kernel=3, max_per_img=100))
work_dir = './work_dirs/centernet_resnet18_140e_coco'
gpu_ids = range(0, 1)

2021-10-28 15:19:57,569 - mmdet - INFO - initialize ResNet with init_cfg {'type': 'Pretrained', 'checkpoint': 'torchvision://resnet18'}
2021-10-28 15:19:57,569 - mmcv - INFO - load model from: torchvision://resnet18
2021-10-28 15:19:57,569 - mmcv - INFO - Use load_from_torchvision loader
2021-10-28 15:19:57,723 - mmcv - WARNING - The model and loaded state dict do not match exactly

unexpected key in source state_dict: fc.weight, fc.bias

loading annotations into memory...
Done (t=0.13s)
creating index...
index created!
loading annotations into memory...
Done (t=0.02s)
creating index...
index created!
2021-10-28 15:20:02,468 - mmdet - INFO - Start running, host: root@dl-1142278230-pod-jupyter-fhx5r, work_dir: /root/nmmdetection/mmdetection/work_dirs/centernet_resnet18_140e_coco
2021-10-28 15:20:02,469 - mmdet - INFO - Hooks will be executed in the following order:
before_run:
(VERY_HIGH   ) StepLrUpdaterHook
(NORMAL      ) CheckpointHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
 --------------------
before_train_epoch:
(VERY_HIGH   ) StepLrUpdaterHook
(NORMAL      ) NumClassCheckHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
 --------------------
before_train_iter:
(VERY_HIGH   ) StepLrUpdaterHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
 --------------------
after_train_iter:
(ABOVE_NORMAL) OptimizerHook
(NORMAL      ) CheckpointHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
 --------------------
after_train_epoch:
(NORMAL      ) CheckpointHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
 --------------------
before_val_epoch:
(NORMAL      ) NumClassCheckHook
(LOW         ) IterTimerHook
(VERY_LOW    ) TextLoggerHook
 --------------------
before_val_iter:
(LOW         ) IterTimerHook
 --------------------
after_val_iter:
(LOW         ) IterTimerHook
 --------------------
after_val_epoch:
(VERY_LOW    ) TextLoggerHook
 --------------------
2021-10-28 15:20:02,469 - mmdet - INFO - workflow: [('train', 1)], max: 28 epochs

stop in here
Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

I found that when I do not change the codes. Sometimes, it stop in the beginning

after_val_epoch:
(VERY_LOW    ) TextLoggerHook

2021-10-28 15:20:02,469 - mmdet - INFO - workflow: [('train', 1)], max: 28 epochs

sometime stop in

2021-10-28 15:20:02,469 - mmdet - INFO - workflow: [('train', 1)], max: 28 epochs then stopped.

2021-10-28 11:20:00,644 - mmdet - INFO - Epoch [1][50/156] lr: 9.990e-04, eta: 3:14:02, time: 2.696, data_time: 2.132, memory: 7312, loss_center_heatmap: 13.3996, loss_wh: 1.5383, loss_offset: 0.4650, loss: 15.4029, grad_norm: 51.5340

When I use the dataset which type is voc
(openmmlab) root@dl-1142278230-pod-jupyter-fhx5r:~/lastestmmdet/mmdetection# python tools/train.py configs/centernet/centernet_resnet18_140e_coco.py
2021-11-01 09:46:06,488 - mmdet - INFO - Environment info:
sys.platform: linux
Python: 3.7.11 (default, Jul 27 2021, 14:32:16) [GCC 7.5.0]
CUDA available: True
GPU 0: Tesla V100-PCIE-32GB
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 10.1, V10.1.243
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.6.0
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) Math Kernel Library Version 2019.0.5 Product Build 20190808 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.5.0 (Git Hash e2ac1fac44c5078ca927cb9b90e1b3066a0b2ed0)
OpenMP 201511 (a.k.a. OpenMP 4.5)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 10.2
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75
CuDNN 7.6.5
Magma 2.5.2
Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DUSE_VULKAN_WRAPPER -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON, USE_STATIC_DISPATCH=OFF,

TorchVision: 0.7.0
OpenCV: 4.5.4-dev
MMCV: 1.3.16
MMCV Compiler: GCC 7.3
MMCV CUDA Compiler: 10.1
MMDetection: 2.18.0+db256a1
2021-11-01 09:46:06,787 - mmdet - INFO - Distributed training: False
2021-11-01 09:46:06,971 - mmdet - INFO - Config:
dataset_type = 'VOCDataset'
data_root = 'data/VOCdevkit/'
img_norm_cfg = dict(
mean=[123.675, 116.28, 103.53], std=[58.395, 57.12, 57.375], to_rgb=True)
train_pipeline = [
dict(type='LoadImageFromFile'),
dict(type='LoadAnnotations', with_bbox=True),
dict(type='Resize', img_scale=(1024, 1024), keep_ratio=True),
dict(type='RandomFlip', flip_ratio=0.5),
dict(
type='Normalize',
mean=[123.675, 116.28, 103.53],
std=[58.395, 57.12, 57.375],
to_rgb=True),
dict(type='Pad', size_divisor=32),
dict(type='DefaultFormatBundle'),
dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels'])
]
test_pipeline = [
dict(type='LoadImageFromFile'),
dict(
type='MultiScaleFlipAug',
img_scale=(1024, 1024),
flip=False,
transforms=[
dict(type='Resize', keep_ratio=True),
dict(type='RandomFlip'),
dict(
type='Normalize',
mean=[123.675, 116.28, 103.53],
std=[58.395, 57.12, 57.375],
to_rgb=True),
dict(type='Pad', size_divisor=32),
dict(type='ImageToTensor', keys=['img']),
dict(type='Collect', keys=['img'])
])
]
data = dict(
samples_per_gpu=36,
workers_per_gpu=2,
train=dict(
type='RepeatDataset',
times=3,
dataset=dict(
type='VOCDataset',
ann_file=['data/VOCdevkit/VOC2007/ImageSets/Main/train.txt'],
img_prefix=['data/VOCdevkit/VOC2007/'],
pipeline=[
dict(type='LoadImageFromFile'),
dict(type='LoadAnnotations', with_bbox=True),
dict(type='Resize', img_scale=(1024, 1024), keep_ratio=True),
dict(type='RandomFlip', flip_ratio=0.5),
dict(
type='Normalize',
mean=[123.675, 116.28, 103.53],
std=[58.395, 57.12, 57.375],
to_rgb=True),
dict(type='Pad', size_divisor=32),
dict(type='DefaultFormatBundle'),
dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels'])
])),
val=dict(
type='VOCDataset',
ann_file='data/VOCdevkit/VOC2007/ImageSets/Main/val.txt',
img_prefix='data/VOCdevkit/VOC2007/',
pipeline=[
dict(type='LoadImageFromFile'),
dict(
type='MultiScaleFlipAug',
img_scale=(1024, 1024),
flip=False,
transforms=[
dict(type='Resize', keep_ratio=True),
dict(type='RandomFlip'),
dict(
type='Normalize',
mean=[123.675, 116.28, 103.53],
std=[58.395, 57.12, 57.375],
to_rgb=True),
dict(type='Pad', size_divisor=32),
dict(type='ImageToTensor', keys=['img']),
dict(type='Collect', keys=['img'])
])
]),
test=dict(
type='VOCDataset',
ann_file='data/VOCdevkit/VOC2007/ImageSets/Main/test.txt',
img_prefix='data/VOCdevkit/VOC2007/',
pipeline=[
dict(type='LoadImageFromFile'),
dict(
type='MultiScaleFlipAug',
img_scale=(1024, 1024),
flip=False,
transforms=[
dict(type='Resize', keep_ratio=True),
dict(type='RandomFlip'),
dict(
type='Normalize',
mean=[123.675, 116.28, 103.53],
std=[58.395, 57.12, 57.375],
to_rgb=True),
dict(type='Pad', size_divisor=32),
dict(type='ImageToTensor', keys=['img']),
dict(type='Collect', keys=['img'])
])
]))
evaluation = dict(interval=1, metric='mAP')
optimizer = dict(type='SGD', lr=0.02, momentum=0.9, weight_decay=0.0001)
optimizer_config = dict(grad_clip=dict(max_norm=35, norm_type=2))
lr_config = dict(
policy='step',
warmup='linear',
warmup_iters=1000,
warmup_ratio=0.001,
step=[18, 24])
runner = dict(type='EpochBasedRunner', max_epochs=300)
checkpoint_config = dict(interval=1)
log_config = dict(interval=50, hooks=[dict(type='TextLoggerHook')])
custom_hooks = [dict(type='NumClassCheckHook')]
dist_params = dict(backend='nccl')
log_level = 'INFO'
load_from = None
resume_from = None
workflow = [('train', 1)]
model = dict(
type='CenterNet',
backbone=dict(
type='ResNet',
depth=18,
norm_eval=False,
norm_cfg=dict(type='BN'),
init_cfg=dict(type='Pretrained', checkpoint='torchvision://resnet18')),
neck=dict(
type='CTResNetNeck',
in_channel=512,
num_deconv_filters=(256, 128, 64),
num_deconv_kernels=(4, 4, 4),
use_dcn=False),
bbox_head=dict(
type='CenterNetHead',
num_classes=6,
in_channel=64,
feat_channel=64,
loss_center_heatmap=dict(type='GaussianFocalLoss', loss_weight=1.0),
loss_wh=dict(type='L1Loss', loss_weight=0.1),
loss_offset=dict(type='L1Loss', loss_weight=1.0)),
train_cfg=None,
test_cfg=dict(topk=100, local_maximum_kernel=3, max_per_img=100))
work_dir = './work_dirs/centernet_resnet18_140e_coco'
gpu_ids = range(0, 1)
2021-11-01 09:46:07,148 - mmdet - INFO - initialize ResNet with init_cfg {'type': 'Pretrained', 'checkpoint': 'torchvision://resnet18'}
2021-11-01 09:46:07,149 - mmcv - INFO - load model from: torchvision://resnet18
2021-11-01 09:46:07,149 - mmcv - INFO - Use load_from_torchvision loader
2021-11-01 09:46:07,241 - mmcv - WARNING - The model and loaded state dict do not match exactly
unexpected key in source state_dict: fc.weight, fc.bias
2021-11-01 09:46:14,535 - mmdet - INFO - Start running, host: root@dl-1142278230-pod-jupyter-fhx5r, work_dir: /root/lastestmmdet/mmdetection/work_dirs/centernet_resnet18_140e_coco
2021-11-01 09:46:14,536 - mmdet - INFO - Hooks will be executed in the following order:
before_run:
(VERY_HIGH   ) StepLrUpdaterHook
(NORMAL      ) CheckpointHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
before_train_epoch:
(VERY_HIGH   ) StepLrUpdaterHook
(NORMAL      ) NumClassCheckHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
before_train_iter:
(VERY_HIGH   ) StepLrUpdaterHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
after_train_iter:
(ABOVE_NORMAL) OptimizerHook
(NORMAL      ) CheckpointHook
(LOW         ) IterTimerHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
after_train_epoch:
(NORMAL      ) CheckpointHook
(LOW         ) EvalHook
(VERY_LOW    ) TextLoggerHook
before_val_epoch:
(NORMAL      ) NumClassCheckHook
(LOW         ) IterTimerHook
(VERY_LOW    ) TextLoggerHook
before_val_iter:
(LOW         ) IterTimerHook
after_val_iter:
(LOW         ) IterTimerHook
after_val_epoch:
(VERY_LOW    ) TextLoggerHook
after_run:
(VERY_LOW    ) TextLoggerHook
2021-11-01 09:46:14,537 - mmdet - INFO - workflow: [('train', 1)], max: 300 epochs
2021-11-01 09:46:14,537 - mmdet - INFO - Checkpoints will be saved to /root/lastestmmdet/mmdetection/work_dirs/centernet_resnet18_140e_coco by HardDiskBackend.
2021-11-01 09:47:59,687 - mmdet - INFO - Epoch [1][50/214]      lr: 9.990e-04, eta: 1 day, 13:28:14, time: 2.103, data_time: 0.519, memory: 21603, loss_center_heatmap: 30.6203, loss_wh: 1.4170, loss_offset: 0.4195, loss: 32.4568, grad_norm: 112.8104
2021-11-01 09:49:26,658 - mmdet - INFO - Epoch [1][100/214]     lr: 1.998e-03, eta: 1 day, 10:12:23, time: 1.739, data_time: 0.142, memory: 21603, loss_center_heatmap: 3.8281, loss_wh: 1.4484, loss_offset: 0.3195, loss: 5.5960, grad_norm: 5.6225
2021-11-01 09:50:51,520 - mmdet - INFO - Epoch [1][150/214]     lr: 2.997e-03, eta: 1 day, 8:51:07, time: 1.697, data_time: 0.091, memory: 21603, loss_center_heatmap: 3.5224, loss_wh: 1.4239, loss_offset: 0.2561, loss: 5.2024, grad_norm: 5.4901
2021-11-01 09:52:15,438 - mmdet - INFO - Epoch [1][200/214]     lr: 3.996e-03, eta: 1 day, 8:04:44, time: 1.678, data_time: 0.087, memory: 21603, loss_center_heatmap: 3.3468, loss_wh: 1.4444, loss_offset: 0.2486, loss: 5.0398, grad_norm: 5.0586
2021-11-01 09:52:38,171 - mmdet - INFO - Saving checkpoint at 1 epochs
[                                                  ] 0/660, elapsed: 0s, ETA:Traceback (most recent call last):
File "tools/train.py", line 189, in
main()
File "tools/train.py", line 185, in main
meta=meta)
File "/root/lastestmmdet/mmdetection/mmdet/apis/train.py", line 177, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 127, in run
epoch_runner(data_loaders[i], **kwargs)
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 54, in train
self.call_hook('after_train_epoch')
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/base_runner.py", line 307, in call_hook
getattr(hook, fn_name)(self)
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/hooks/evaluation.py", line 267, in after_train_epoch
self._do_evaluate(runner)
File "/root/lastestmmdet/mmdetection/mmdet/core/evaluation/eval_hooks.py", line 18, in _do_evaluate
results = single_gpu_test(runner.model, self.dataloader, show=False)
File "/root/lastestmmdet/mmdetection/mmdet/apis/test.py", line 28, in single_gpu_test
result = model(return_loss=False, rescale=True, **data)
File "/root/.local/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
result = self.forward(*input, **kwargs)
File "/root/.local/lib/python3.7/site-packages/mmcv/parallel/data_parallel.py", line 42, in forward
return super().forward(*inputs, **kwargs)
File "/root/.local/lib/python3.7/site-packages/torch/nn/parallel/data_parallel.py", line 153, in forward
return self.module(*inputs[0], **kwargs[0])
File "/root/.local/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
result = self.forward(*input, **kwargs)
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 98, in new_func
return old_func(*args, **kwargs)
File "/root/lastestmmdet/mmdetection/mmdet/models/detectors/base.py", line 174, in forward
return self.forward_test(img, img_metas, **kwargs)
File "/root/lastestmmdet/mmdetection/mmdet/models/detectors/base.py", line 147, in forward_test
return self.simple_test(imgs[0], img_metas[0], **kwargs)
File "/root/lastestmmdet/mmdetection/mmdet/models/detectors/single_stage.py", line 103, in simple_test
feat, img_metas, rescale=rescale)
File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/base_dense_head.py", line 351, in simple_test
return self.simple_test_bboxes(feats, img_metas, rescale=rescale)
File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/dense_test_mixins.py", line 38, in simple_test_bboxes
*outs, img_metas=img_metas, rescale=rescale)
File "/root/.local/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 186, in new_func
return old_func(*args, **kwargs)
File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/centernet_head.py", line 294, in get_bboxes
with_nms=with_nms))
File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/centernet_head.py", line 338, in _get_bboxes_single
batch_border = det_bboxes.new_tensor(img_meta['border'])[...,
KeyError: 'border'
(openmmlab) root@dl-1142278230-pod-jupyter-fhx5r:~/lastestmmdet/mmdetection#

File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/centernet_head.py", line 338, in _get_bboxes_single
batch_border = det_bboxes.new_tensor(img_meta['border'])[...,
KeyError: 'border'

Please follow the test_pipeline in configs/centernet/centernet_resnet18_dcnv2_140e_coco.py , and add RandomCenterCropPad to your config. Currently, this transform is necessary for CenterNet.

When I use that, it stoped.
I gave up, I finally used the original Centernet.
Thank you very much!

File "/root/lastestmmdet/mmdetection/mmdet/models/dense_heads/centernet_head.py", line 338, in _get_bboxes_single
batch_border = det_bboxes.new_tensor(img_meta['border'])[...,
KeyError: 'border'

Please follow the test_pipeline in configs/centernet/centernet_resnet18_dcnv2_140e_coco.py , and add RandomCenterCropPad to your config. Currently, this transform is necessary for CenterNet.

This is stupid

authors: RangiLyu bennyji taofuyu


text:
DataLoader worker (pid(s) 659) exited unexpectedly

I keep getting this runtime error when trying to train YOLCAT. I am using a batch size of 1 and I am training with 53 images. The images have a size of 4,000 x 2,250. I have successfully trained Mask Scoring R-CNN, Mask R-CNN and HTC with the same set-up. I only changed the config, weights file and 'num_class'. I used the same images...
Any advice would be much appreciated.
I have included the error printout:

@David-Biggs The information provided is relatively small, and it is difficult for me to judge. I guess the possible reason is that there are not enough resources.

@David-Biggs The information provided is relatively small, and it is difficult for me to judge. I guess the possible reason is that there are not enough resources.

Thanks @hhaAndroid!
I am training on Google Colab Pro, which I think generally has sufficient resources (I did initially think that this was the issue).
What additional information do you think I should provide?
Thanks Again.

@David-Biggs It is recommended to run https://github.com/open-mmlab/mmdetection/blob/master/tools/misc/browse_dataset.py first to ensure that there is no problem with the dataloader output.

Closed due to no reply for more than 15 days.

source: gharchive/issue

authors: David-Biggs hhaAndroid

repo: open-mmlab/mmdetection

license_type: permissive

license_source: github-api


text:
How to calculate average recall (AR) of each class

Hi,
After completing each epoch I am getting the following results, but it shows the average recall of all classes. I want to check the average recall of each class. Can anyone please guide me on how to do this?
Thanks.
I was using 5 classes and got the following results.
Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets=100 ] = 0.320
Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets=300 ] = 0.320
Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets=1000 ] = 0.320
Average Recall (AR) @[ IoU=0.50:0.95 | area= small | maxDets=1000 ] = 0.128
Average Recall (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=1000 ] = 0.303
Average Recall (AR) @[ IoU=0.50:0.95 | area= large | maxDets=1000 ] = 0.341

@ibrahim1611 python test.py xxxx --eval-options evaluation.classwise=True

@hhaAndroid It only shows the average precision (AP) of each class.

@ibrahim1611 Sorry. Currently no support.

@ibrahim1611 Sorry. Currently no support.

so how to do it ?

Option 1:
Go to mmdetection/mmdet/evaluation/metrics/coco_metrics.py  file and change classwise: bool = False to classwise: bool = True in COCOmetric initializer. This will create mAP values of different thresholds (same format as general mAP information) for each class as follows:

If you want to obtain AR values in the same way, you can go to line 520
if self.classwise:  # Compute per-category AP
               precisions = coco_eval.eval['precision']

Option 2:

Implement classwise precision and recall functions (taken from official GroundingDINO implementation)
import itertools
from tabulate import tabulate

def per_class_AR_table(coco_eval, class_names=None, headers=["class", "AR"], colums=6):
    per_class_AR = {}
    recalls = coco_eval.eval["recall"]
    # dimension of recalls: [TxKxAxM]
    # recall has dims (iou, cls, area range, max dets)
    assert len(class_names) == recalls.shape[1]

    for idx, name in enumerate(class_names):
        recall = recalls[:, idx, 0, -1]
        recall = recall[recall > -1]
        ar = np.mean(recall) if recall.size else float("nan")
        per_class_AR[name] = float(ar * 100)

    num_cols = min(colums, len(per_class_AR) * len(headers))
    result_pair = [x for pair in per_class_AR.items() for x in pair]
    row_pair = itertools.zip_longest(*[result_pair[i::num_cols] for i in range(num_cols)])
    table_headers = headers * (num_cols // len(headers))
    table = tabulate(
        row_pair, tablefmt="pipe", floatfmt=".3f", headers=table_headers, numalign="left",
    )
    return table

def per_class_AP_table(coco_eval, class_names=None, headers=["class", "AP"], colums=6):
    per_class_AP = {}
    precisions = coco_eval.eval["precision"]
    # dimension of precisions: [TxRxKxAxM]
    # precision has dims (iou, recall, cls, area range, max dets)
    assert len(class_names) == precisions.shape[2]

    for idx, name in enumerate(class_names):
        # area range index 0: all area ranges
        # max dets index -1: typically 100 per image
        precision = precisions[:, :, idx, 0, -1]
        precision = precision[precision > -1]
        ap = np.mean(precision) if precision.size else float("nan")
        per_class_AP[name] = float(ap * 100)

    num_cols = min(colums, len(per_class_AP) * len(headers))
    result_pair = [x for pair in per_class_AP.items() for x in pair]
    row_pair = itertools.zip_longest(*[result_pair[i::num_cols] for i in range(num_cols)])
    table_headers = headers * (num_cols // len(headers))
    table = tabulate(
        row_pair, tablefmt="pipe", floatfmt=".3f", headers=table_headers, numalign="left",
    )
    return table

and call them as follows in the same lines:
if self.classwise:  # Compute per-category AP
               info = ""
               AP_table = per_class_AP_table(coco_eval, class_names=cat_list)
               info += "per class AP:\n" + AP_table + "\n"

               AR_table = per_class_AR_table(coco_eval, class_names=cat_list)
               info += "per class AR:\n" + AR_table + "\n"

               print(info)

This solution will create the following output:


text:
Provide inference of Detic

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Provide inference of Detic.
Modification
Add Detic1 to projects.

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

Hi @ryylcc,
We'd like to express our appreciation for your valuable contributions to the mmdetection. Your efforts have significantly aided in enhancing the project's quality.
It is our pleasure to invite you to join our community thorugh Discord_Special Interest Group (SIG) channel. This is a great place to share your experiences, discuss ideas, and connect with other like-minded people. To become a part of the SIG channel, send a message to the moderator, OpenMMLab, briefly introduce yourself and mention your open-source contributions in the #introductions channel. Our team will gladly facilitate your entry. We eagerly await your presence. Please follow this link to join us: https://discord.gg/UjgXkPWNqA.
If you're on WeChat, we'd also love for you to join our community there. Just add our assistant using the WeChat ID: openmmlabwx. When sending the friend request, remember to include the remark "mmsig + Github ID".
Thanks again for your awesome contribution, and we're excited to have you as part of our community!

source: gharchive/pull-request


text:
[Fix] Fix num_last_epochs logic for the hooks in YOLOX training

Motivation
Based on #7284 , I ran a few more experiments with  num_last_epochs.
I could still see that the  before_train_epoch hooks didn't come in at the proper epoch.
They came in one epoch earlier than I expected them to, so I made a PR to fix it.
On the other hand, the learning rate schedule, which is the learning rate is fixed during the  num_last_epochs, works fine.
This means that the  number of epochs for fixed learning rate and the  number of epochs for non-mixup-mosaic augmentation didn't match as well.
Modification
I modified two files,  sync_norm_hook.py and   yolox_mode_switch_hook.py that implement  before_train_epoch hook using  num_last_epochs.
In both of the files, the if logic was modified from
        if (epoch + 1) == runner.max_epochs - self.num_last_epochs:

to
        if epoch == runner.max_epochs - self.num_last_epochs:

BC-breaking (Optional)
Yes
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
The documentation has been modified accordingly, like docstring or example tutorials.

The official YOLOX code also adds one more epoch. https://github.com/Megvii-BaseDetection/YOLOX/pull/1152 proposes a fix for the code.
Since the authors have not commented so far, we cannot determine whether it is a bug or an intentional specification.
If it is intentional,
num_last_epochs=15 -> num_last_epochs=16 in yolox_mode_switch_hook.py, sync_norm_hook.py

This PR makes a BC-breaking change.
If we want to reproduce the settings of the published trained models, we need to modify yolox_s_8x8_300e_coco.py.
For users that use their own configs, it is worth considering raising warnings.

@shinya7y The author in the paper says

We adopt the MixUp and Mosaic implementation in our model and close it for the last 15 epochs

So I think it's a bug but let's wait for the answer.
What a coincidence that person made a PR 1 day after I published an issue here :)

@HJoonKwon Sorry for the late reply. Although the understanding is a bit wrong, in fact, this is not a bug, this is completely according to the official way of writing. If num_last_epochs=15, it means switching from 300-15

@hhaAndroid Still confused.. Switching from 300-15(in the meta data perspective) means that training closes the augmentation from 285th epoch to 300th epoch. And that is 16 epochs, not 15 epochs. There might be some confusion in the 'writing' in the paper. But, sure we may wait! :)

Have you tried it? Are there any differences in the results？

While the official code still haven't updated. I would suggest that the +1 be removed from num_last_epochs , and setting it to 16 in the configs with a comment that leads to these discussions.
This could be extra confusing as mentioned in #8560, when people expect to tune off this thing through num_last_epochs=0.

authors: HJoonKwon hhaAndroid nemonameless shinya7y voldemortX


text:
Release plan for MV-FCOS3D++

Hi, I saw that the codebase for MV-FCOS3D++ used in Waymo 2D challenge is planned to release on mmdetection3d. When might the code be released?
Also, I was wondering what exactly the "FCOS3D++" model was compared to FCOS3D

The code of MV-FCOS3D++ for camera-only 3D detection will be released in a month if everything goes well.
The "FCOS3D++" model is basically similar to the released version of PGD. It only serves as a monocular baseline for pretraining the backbone for perspective view parsing in the MV-FCOS3D++. Please refer to the report for more details.

The code of MV-FCOS3D++ together with our recent work DfM are preliminarily released here. We will further refine it recently and support them in the mmdet3d. Please stay tuned.

authors: Divadi Tai-Wang


text:
Wind Onshore Installed Capacity for HB and HH

@chrwm Can you please check, if the Installed Capacities for Wind Onshore for HB and HH are correct? It seems that there is a decimal error for the 2030/2050 values.

See it's been fixed right now, will check the new data and then close the issue if it's fixed!

repo: open-modex/models


text:
redesignv2: Inconsistent escaping of quotes

I seem to notice an inconsistent escaping of quotes when querying for tasks:
Steps to reproduce (using redesignv2 checkout)
exact.repos.txt
 ros2 launch rmf_demos_ign office.launch.xml headless:=1 server_uri:=ws://localhost:8001 use_sim_time:=false

 rmf_api_server

ros2 run rmf_demos_tasks dispatch_teleop  -s coe

 curl -X 'GET'   'http://localhost:8000/tasks?task_id=compose.dispatch-0&limit=100&offset=0'   -H 'accept: application/json'

Gives this output
[
  {
    "booking": {
      "id": "compose.dispatch-0",
      "unix_millis_earliest_start_time": 0,
      "priority": null,
      "labels": null
    },
    "category": "teleop",
    "detail": {},
    "unix_millis_start_time": null,
    "unix_millis_finish_time": null,
    "original_estimate_millis": 60000,
    "estimate_millis": 84267,
    "assigned_to": {
      "group": "tinyRobot",
      "name": "tinyRobot1"
    },
    "status": "underway",
    "dispatch": null,
    "phases": {
      "1": {
        "id": 1,
        "category": "Sequence",
        "detail": "[{\"category\":\"Go to [place:coe]\",\"detail\":\"Moving the robot from [place:tinyRobot1_charger] to [place:coe]\"},{\"category\":\"Perform action\",\"detail\":\"Performing action teleop at waypoint [[place:coe]]\"}]",
        "unix_millis_start_time": null,
        "unix_millis_finish_time": null,
        "original_estimate_millis": 87509,
        "estimate_millis": 84267,
        "final_event_id": 0,
        "events": {
          "0": {
            "id": 0,
            "status": "underway",
            "name": "Sequence",
            "detail": {},
            "deps": [
              1,
              2
            ]
          },
          "1": {
            "id": 1,
            "status": "underway",
            "name": "Go to [place:coe]",
            "detail": "Moving the robot from [place:tinyRobot1_charger] to [place:coe]",
            "deps": [
              4,
              3,
              8
            ]
          },
          "2": {
            "id": 2,
            "status": "standby",
            "name": "Perform action",
            "detail": "Performing action teleop at waypoint [[place:tinyRobot1_charger]]",
            "deps": []
          },
          "3": {
            "id": 3,
            "status": "standby",
            "name": "Pass through [door:coe_door]",
            "detail": {},
            "deps": [
              5,
              6,
              7
            ]
          },
          "4": {
            "id": 4,
            "status": "underway",
            "name": "Move [tinyRobot/tinyRobot1] to ( 8.91186 -6.18135  2.76447)",
            "detail": {},
            "deps": []
          },
          "5": {
            "id": 5,
            "status": "standby",
            "name": "Open door \"coe_door\"",
            "detail": {},
            "deps": []
          },
          "6": {
            "id": 6,
            "status": "standby",
            "name": "Move [tinyRobot/tinyRobot1] to ( 6.51731 -5.23293  2.76447)",
            "detail": {},
            "deps": []
          },
          "7": {
            "id": 7,
            "status": "standby",
            "name": "Close door \"coe_door\"",
            "detail": {},
            "deps": []
          },
          "8": {
            "id": 8,
            "status": "standby",
            "name": "Move [tinyRobot/tinyRobot1] to ( 5.34648 -4.97681  2.92624)",
            "detail": {},
            "deps": []
          }
        },
        "skip_requests": null
      }
    },
    "completed": [],
    "active": 1,
    "pending": [],
    "interruptions": null,
    "cancellation": null,
    "killed": null
  }
]

I'm not sure if this is any issue, especially when output on the upcoming event viewer

I think this is a bug on rmf side, you can test it by turning on debug logs
RMF_API_SERVER_LOG_LEVEL=DEBUG npm start | grep task_state_update

DEBUG:fastapi.RmfGatewayApp:{'data': {'active': 1, 'assigned_to': {'group': 'tinyRobot', 'name': 'tinyRobot1'}, 'booking': {'id': 'compose.dispatch-0', 'unix_millis_earliest_start_time': 1644198634002}, 'category': 'teleop', 'completed': [], 'detail': '', 'estimate_millis': 84557, 'original_estimate_millis': 60000, 'pending': [], 'phases': {'1': {'category': 'Sequence', 'detail': '[{"category":"Go to [place:coe]","detail":"Moving the robot from [place:tinyRobot1_charger] to [place:coe]"},{"category":"Perform action","detail":"Performing action teleop at waypoint [[place:coe]]"}]', 'estimate_millis': 84557, 'events': {'0': {'deps': [1, 2], 'detail': '', 'id': 0, 'name': 'Sequence', 'status': 'underway'}, '1': {'deps': [4, 3, 8], 'detail': 'Moving the robot from [place:tinyRobot1_charger] to [place:coe]', 'id': 1, 'name': 'Go to [place:coe]', 'status': 'underway'}, '2': {'deps': [], 'detail': 'Performing action teleop at waypoint [[place:tinyRobot1_charger]]', 'id': 2, 'name': 'Perform action', 'status': 'standby'}, '3': {'deps': [5, 6, 7], 'detail': '', 'id': 3, 'name': 'Pass through [door:coe_door]', 'status': 'standby'}, '4': {'deps': [], 'detail': '', 'id': 4, 'name': 'Move [tinyRobot/tinyRobot1] to ( 8.91186 -6.18135  2.76447)', 'status': 'underway'}, '5': {'deps': [], 'detail': '', 'id': 5, 'name': 'Open door "coe_door"', 'status': 'standby'}, '6': {'deps': [], 'detail': '', 'id': 6, 'name': 'Move [tinyRobot/tinyRobot1] to ( 6.51731 -5.23293  2.76447)', 'status': 'standby'}, '7': {'deps': [], 'detail': '', 'id': 7, 'name': 'Close door "coe_door"', 'status': 'standby'}, '8': {'deps': [], 'detail': '', 'id': 8, 'name': 'Move [tinyRobot/tinyRobot1] to ( 5.34648 -4.97681  2.92624)', 'status': 'standby'}}, 'final_event_id': 0, 'id': 1, 'original_estimate_millis': 87509}}, 'status': 'underway', 'unix_millis_finish_time': 1644198771922, 'unix_millis_start_time': 1644198636257}, 'type': 'task_state_update'}

The above shows the message received from rmf "as is", notice that the details field is a string.

authors: cnboonhan koonpeng

repo: open-rmf/rmf-web


text:
Favorite tasks

What's new
Favorite tasks are added.

The user will be able to create favorite tasks for those he/she considers recurrent.

The user will be able to edit his/her favorite tasks.

The user will be able to delete his/her favorite tasks.

chrome-capture-2023-1-13.webm
chrome-capture-2023-1-13 (1).webm
chrome-capture-2023-1-13 (2).webm
chrome-capture-2023-1-13 (3).webm

Self-checks

[ ] I have prototyped this new feature (if necessary) on Figma
[ ] I'm familiar with and follow this Typescript guideline
[ ] I added unit-tests for new components
[ ] I tried testing edge cases
[ ] I tested the behavior of the components that interact with the backend, with an e2e test

Discussion

Per VC, we will be merging this into deploy/hammer, to be backported into main after https://github.com/open-rmf/rmf_api_msgs/pull/33 and all other API changes for this project has been merged. This will help us reduce the number of PRs for generation of API messages for the API server, and allow us to fix any incoming broken behaviors once the API is updated.

I noticed that there was a bunch of commits that were not signed earlier in this PR, I don't think it is a big deal, but let's make sure each commit is properly signed with gpg next time. Thanks!

authors: Angatupyry aaronchongth


text:
python module for rmf_api_msgs schemas

The objective here is to make the rmf_api_msgs schemas and data models available to users as a python package. Similar to the existing cpp header generation, the schemas here are generated as python functions. After compilation, users can obtain the schemas and data models by just importing the rmf_api_msgs python module.
Description

During compilation of rmf_api_msgs pkg, cmakelist will run 2 commands to generate the python rmf_api_msgs.schemas and rmf_api_msgs.models:
rmf_api_msgs.schemas

Execute generate_py_schemas.py. It will load all existing /schemas/*.json, and generate schemas.py according to the template: schemas_template.jinja2

rmf_api_msgs.models:

This depends on an external datamodel generation pkg: data-model-codegen
data-model-codegen script will generate respective data models according to the schemas. The output is located at rmf_api_msgs/rmf_api_msgs/models/*

Lastly, ament_python_install_package() in the cmakelist will install the rmf_api_msgs module
The implementation here is very experimental, not sure if this is the "right way" to generate py schemas and models.
[NOT RELEVANT] Also, added some minor printout in rust scripts for verbosity, greatly help in debugging

To Test
To view the python modules:
colcon build --packages-select rmf_api_msgs
source install.setup
python3
>>> import rmf_api_msgs.schemas as schemas
>>> from rmf_api_msgs.models import task_state
>>> help(schemas)
>>> help(task_state)

Simple validation script in py:
ros2 run rmf_api_msgs check_sample.py -i src/rmf_api_msgs/rmf_api_msgs/samples/task_log/multi_dropoff_delivery.json --task_log

**Maybe shouldn't depend on  ament_cmake here??
Feedback is more than welcome.

Thanks for testing it. The reason for using ament_cmake is to install the python scripts as a package of rmf_api_msgs via the existing cmakelist, specifically with ament_python_install_package(). Hopefully export it as ament_cmake will also make this pkg discoverable as an ament or ros2 pkg, helps in rosdep.


text:
fix: update schema utils to fix browser issue

fixes #227

:tada: This PR is included in version 1.12.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: openrpc-bastion shanejonas

repo: open-rpc/generator-client


text:
feat: update onboarding steps

What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description

Updates the onboarding steps to match the new design linked in the issue
Related Tickets & Documents

closes #801
Mobile & Desktop Screenshots/Recordings
Step 2:

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Need the images (with the active and normal variants) of the new steps for the left side:

Are they not exportable in Figma? "Export as SVG"

Are they not exportable in Figma? "Export as SVG"

Tried, but they weren't exported with the circle, or maybe I don't know how to properly export them

@getaheaddev perhaps you can share/upload step 2/3 active/inactive svgs first thing tomorrow.

I'm also facing issues with the backend.
1- with /auth/onboarding:

I keep getting server error 500 when trying to send a request to it. I tried with body of "" & and with body of {"id": []} (inspired by how it is called in frontend) and in both I get the same error.
Side note: I don't know how onboarding in api was made, but given that the frontend used to send repo ids to it, that may need changing (since onboarding no longer collects repo ids).

2- with /auth/profile:

When I try to send a request with name, email (sending them because they are required), and timezone, I get error 404 and message "user not found". It works if I omit the timezone.
Suggestion: Would it be possible to make the endpoint not require name & email? As in my use-case I only need to update the timezone of the user.

@Deadreyo is still blocked? I think @0-vortex shipped a fix.

The /auth/onboarding endpoint has been updated to accept the new onboarding fields
https://beta.api.opensauced.pizza/#/Authentication service/postOnboarding

The /auth/onboarding endpoint has been updated to accept the new onboarding fields

Cool. I get a message everyday from people confused by the onboarding.

The /auth/onboarding endpoint has been updated to accept the new onboarding fields
https://beta.api.opensauced.pizza/#/Authentication service/postOnboarding

The issue that I've reported to you still persists:
Error 400: { 	"message": [ 		"interests must be an array", 		"timezone must be a string" 	] }
on sending {"interests":["javascript","react"],"timezone":"Egypt Standard Time"}

Frontend-wise, this PR is ready for review. Backend-wise, onboarding won't work due to api issues but that can be fixed async. We can save time if we want this asap by reviewing it early (excluding the api thing).

Frontend-wise, this PR is ready for review. Backend-wise, onboarding won't work due to api issues but that can be fixed async. We can save time if we want this asap by reviewing it early (excluding the api thing).

Can you update description with screenshots of all steps?

Can you update description with screenshots of all steps?

Updated

The deploy preview is failing to build

@Deadreyo onboarding images are still broken

All the keys here should be lowercase to match the interests
https://github.com/open-sauced/insights/blob/3d6fa77c9fcb18e6a2088aa148f58752422f14fc/components/atoms/LanguagePill/LanguagePill.tsx#L19

authors: Deadreyo bdougie brandonroberts

repo: open-sauced/insights


text:
Which NLP solver to use?

@donboyd5, @evtedeschi3 please feel free to rename as you see fit. You two are the admins.

Are you wedded to IPOPT? What about other options in R like nleqslv?
I am not an expert on nonlinear solvers, but have worked with many and have developed satisficing preferences after extensive experimentation.
A) We need an NLP solver that, at a miniumum:

Can impose bounds on variables (most can), sometimes called box constraints. In our case, our variables (the x[i] adjustment factors that are multiplied by record weights to arrive at adjusted weights) will need to be >=0 and we may want to impose upper bounds, too.

Can handle linear equality and inequality constraints. In our case, an equality constraint might be that we want the number of returns calculated with the new, adjusted weights, to equal 12 million for the state of California. An inequality constraint might be that we want total capital gains income in the $75-100k agi range in California, calculated using the new, adjusted weights, to fall between $42 billion and $44 billion. (These numbers are all made up.)

Any NLP solver that can do this, AND solve our problem (no matter how large or complicated it gets), will work.
B) However, some variants of our problem can get large, complicated, and hard to solve. In my experience the following attributes of an NLP solver are also valuable:

It can handle sparse constraint-coefficient matrices.

Suppose you have 2 constraints, where x[i] is the adjustment factor we are solving for, wt[i] is the set of weights we are starting with, and cg and pension are capital gains and pensions income on hte file, respectively:
a) The number of returns with positive capital gains must equal 1,000:
left hand side: sum over i:  x[i] * wt[i] * (cg[i] > 0)
RHS:  1000
b) The number of returns with positive pension income must equal 10,000
LHS:  sum over i: x[i] * wt[i] * (pension[i] > 0)
RHS: 10000
A constraint coefficient (cc) is the derivative of the LHS with respect to x[i] - how much will the constraint value on the adjusted file change if we change x[i]? In equation a, the cc is wt[i] for those records where cg[i] is > 0, and zero for all other records (probably most of them). (If we increase x[i] by 1, the value of the LHS of constraint a will change by wt[i] for returns that have capital gains.
Similarly for equation b.
In our case, all of our constraints will be linear functions of x[i], like those above, with no interaction between x[i] and x[something else], and so all of our constraint coefficients will be constants (which is nice for us - they don't have to be recalculated with each new guessed-at set of x[i]'s).
A constraint coefficient matrix (ccm) is a matrix with a row for each i (150k rows, if we are looking at a single state in isolation) and a column for each constraint. In our case, it would be a 150k x 2 matrix. In column 1, corresponding to constraint a, the values would be wt[i] for those records with capital gains, and zero otherwise. Similarly for column 2.
Perhaps only 10% of the elements of the 300k element ccm will be nonzero, but we have reserved space for all 300k. A matrix with a lot of zeros is a sparse matrix.
Some nonlinear solvers take advantage of sparsity, storing only the nonzero values in a compact way (we'll get to that later) and also doing calculations with special methods, making them much more able to deal with very large problems. (Imagine that we got to a situation where we had 8 million records and 1,000 constraints, for a 9 billion element constraint coefficient matrix. Suppose further - and this is not unrealistic - that only 4% of the elements, or 360 million, were nonzero. It would be a good candidate for sparse matrix methods.)
Anyway, Ipopt can use sparse matrix methods making it well suited for large problems.

Ipopt is an interior point solver. Another common class of solver methods is based on generalized reduced gradient methods. Interior point methods seem to work very well on large convex problems like ours are likely to be. But I don't know much more about it than that.

Nonlinear solvers rely on linear solvers for part of their work. When problems get large, linear solvers that store the entire problem in memory (even on my 32 gb RAM machine) can choke and swap out memory, slowing them down. And some linear solvers simply work better than others. Ipopt allows you to decide which linear solvers to use, and in particular can use the Harwell Subroutine Library solvers, including one known as MA77, which does most of its work out of memory and is well-suited to huge problems.

So, Ipopt coupled with MA77 seems to be able to solve absolutely huge problems that have a structure similar to ours. I have had some NLP solver and linear solver combinations run for days and weeks, but I think this combination will generally solve our problems, robustly, in seconds or minutes.
That said, maybe what we are doing now won't get that large. Other NLP solvers may be perfectly appropriate. It's not really up to me to decide what we use. I am fine with experimentation. I have experimented with probably a dozen nonlinear solvers and a half-dozen linear solvers, and settled on this combination, but it is very hard to get it all working the very first time. After that, it is easy forever after.
So bottom line, whatever you find works for the problem, in acceptable time, should be fine.
As for nleqslv, I don't think that is an NLP solver - it solves systems of nonlinear equations, but I don't think is an optimizer.

On Fri, 22 Dec 2017, Don Boyd wrote:

Are you wedded to IPOPT? What about other options in R like nleqslv?

I believe SNOPT from Stanford also allows sparse matrices and might be
suitable. I looked at it when I was frustrated by all the different
libraries IPOPT required, but got IPOPT working before actually tryiing
SNOPT out.
Can I ask for a description of the object of this excercise? I thought it
was to impute state of residence to PUF returns, but the example given is
to modify weights given a state of residence. So the purpose is to take
state of residence from the 2008 PUF and modify weights till the totals
add up to published aggregates? What about the >200K returns?
dan

I just elaborated on the objective, at https://github.com/open-source-economics/PUF-State-Distribution/blob/master/README.md - please see if that makes sense.

I don't think SNOPT is available through R. It could be accessed by other means.

On Fri, 22 Dec 2017, Don Boyd wrote:

I don't think SNOPT is available through R. It could be accessed by other means.

Yes, if R is required.
I wonder about the desirability of an out-of-memory linear solver. The
total memory taken by this problem is large for a desktop, but quite
reasonable for a modest size server. Even 64GB would allow the solver to
stay in memory (with sparse matrix support) and I would have to believe
that would be a great time-saver.
We can certainly use the system here - we have R and IOPT, although I have
never combined them.
dan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the
thread.[AHvQVWPzhK-niAh55SYaPuDpeNVyXk_oks5tDBKGgaJpZM4RLQP7.gif]

Thanks for offering use of the system you have. It is definitely good to know that is a possibility. I'm actually not sure yet how large or difficult this problem will become and I am very optimistic that it will be solvable on commodity equipment. A few comments:

The memory requirements of the approach you and I discussed early/mid 2017 were much greater than we have been discussing here. There we were talking about assigning 70k uncoded records to 50 states in a way that exhausted each record exactly. That required us to solve for 3.5 million proportions (50 proportions x 70k records) and to impose a constraint on every single record that the proportions, across states, add to 1 -- every record is used completely, whether assigned all to one state, 60% to one state and 40% to another, or 2% to each of 50 states, or something else. Thus, we had an NLP with 3.5 million variables, at least 70k constraints (plus all of our substantive targets), and it was relatively large and difficult. Still, it was solvable on commodity equipment in a matter of hours.

The problem we have been discussing here, so far, is much easier. We have been talking about distributing some portion of each record on a (let's say) 160k record file, to each of 50 (approx) states, without worrying about using each record's weight exactly -- we can re-use records or not, as needed. On its face, this might seem big -- we need 8 million variables (the proportion of each of 160k records to be distributed to each of 50 states) and, maybe, 5k constraints (25 substantive targets for each of, let's say, 4 income ranges, for each of 50 states). But each state is separable from the others (since we are not constraining a record across states) and each income range is separable, so that we can solve 200 separate problems:  one state, one income range (50 x 4). The average problem size might entail about 40k records (the approx 40k records for a specific income range -- 160k / 4; of course some will be larger, some smaller) and the 25 constraints for that income range and state. Unless we find reasons to make the problem more complex (e.g., constraints across states or income ranges), this should be pretty easy to solve. (CAUTION: In my experience, problems almost always become more difficult than you think they are at the start.)

IF the problem becomes large, that does not necessarily mean an in-memory solver on a large machine will be better than an out-of-memory solver on a small machine. It is an empirical question. I have done a LOT of tests and timings of this. For example I have solved relatively large problems requiring, say, 24gb of RAM, all in (considering all requirements) on a machine that had 32gb of RAM, both ways: in memory, and out of memory. To do this in memory, the operating system must allocate 24gb of RAM, which is a VERY expensive and time-consuming operation. As a result, the out-of-memory solver, which does not need to do this, can actually be much faster than an in-memory solver even on a problem that fits entirely in memory. But the Ipopt/Harwell HSL combination allows a range of solvers that all are excellent, some of which are in memory (e.g., MA57) and one of which is out-of-memory (MA77).

But again, it is an empirical question, and if the problem becomes much larger than we have been discussing so far, and larger than what is practical on PCs, it is really good to know that we could do it on much larger and faster equipment.

On Sat, 23 Dec 2017, Don Boyd wrote:

Thanks for offering use of the system you have. It is definitely good to know that is a possibility. I'm
actually not sure yet how large or difficult this problem will become and I am very optimistic that it will
be solvable on commodity equipment. A few comments:

The memory requirements of the approach you and I discussed early/mid 2017 were much greater than we
have been discussing here. There we were talking about assigning 70k uncoded records to 50 states in a
way that exhausted each record exactly. That required us to solve for 3.5 million proportions (50
proportions x 70k records) and to impose a constraint on every single record that the proportions,
across states, add to 1 -- every record is used completely, whether assigned all to one state, 60% to
one state and 40% to another, or 2% to each of 50 states, or something else. Thus, we had an NLP with
3.5 million variables, at least 70k constraints (plus all of our substantive targets), and it was
relatively large and difficult. Still, it was solvable on commodity equipment in a matter of hours.

Yes, that is right.

The problem we have been discussing here, so far, is much easier. We have been talking about
distributing some portion of each record on a (let's say) 160k record file, to each of 50 (approx)
states, without worrying about using each record's weight exactly -- we can re-use records or not, as
needed. On its face, this might seem big -- we need 8 million variables (the proportion of each of 160k
records to be distributed to each of 50 states) and, maybe, 5k constraints (25 substantive targets for
each of, let's say, 4 income ranges, for each of 50 states). But each state is separable from the others
(since we are not constraining a record across states) and each income range is separable, so that we

I don't know what you mean by "each state is separable". If the aggregates
by state are targets, doesn't that prevent each state from separating from
the others in the same income range?

can solve 200 separate problems: one state, one income range (50 x 4). The average problem size might
entail about 40k records (the approx 40k records for a specific income range -- 160k / 4; of course some

I see, we give up the requirement that the probabilities sum to 1 for each
state. Same number of variables but far fewer constraints. That makes some
sense as a simplification. Does it change the result? Do you get negative
weights? I worry that the randomization of weight sums per record might
affect the accuracy of the federal calculation. Do we use the SOI weight
for the federal aggregates and our random weights for the state level
aggregates? I think that works but do the states add up to the federal?
Don't you get some negative weights? Doesn't that bother you?

will be larger, some smaller) and the 25 constraints for that income range and state. Unless we find
reasons to make the problem more complex (e.g., constraints across states or income ranges), this should
be pretty easy to solve. (CAUTION: In my experience, problems almost always become more difficult than
you think they are at the start.)

I am not doing to well at the moment. IPOPT claims no solution in the
feasible region. Maybe I made a mistake somewhere, so I will work on it.
Oddly, IPOPT doesn't seem to offer a way to look at the values for X
after each step, or any way to look at G when execution terminates. So I
have to jury-rig something.
dan

IF the problem becomes large, that does not necessarily mean an in-memory solver on a large machine will
be better than an out-of-memory solver on a small machine. It is an empirical question. I have done a
LOT of tests and timings of this. For example I have solved relatively large problems requiring, say,
24gb of RAM, all in (considering all requirements) on a machine that had 32gb of RAM, both ways: in
memory, and out of memory. To do this in memory, the operating system must allocate 24gb of RAM, which
is a VERY expensive and time-consuming operation. As a result, the out-of-memory solver, which does not
need to do this, can actually be much faster than an in-memory solver even on a problem that fits
entirely in memory. But the Ipopt/Harwell HSL combination allows a range of solvers that all are
excellent, some of which are in memory (e.g., MA57) and one of which is out-of-memory (MA77).

But again, it is an empirical question, and if the problem becomes much larger than we have been
discussing so far, and larger than what is practical on PCs, it is really good to know that we could do
it on much larger and faster equipment.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the
thread.[AHvQVYkkWUQzvqiyiYMroRd4c07HfRD0ks5tDOmRgaJpZM4RLQP7.gif]

I see, we give up the requirement that the probabilities sum to 1 for each state. Same number of variables but far fewer constraints. That makes some sense as a simplification. Does it change the result? Do you get negative weights? I worry that the randomization of weight sums per record might
affect the accuracy of the federal calculation. Do we use the SOI weight for the federal aggregates and our random weights for the state level aggregates? I think that works but do the states add up to the federal? Don't you get some negative weights? Doesn't that bother you?

If we do every state independently, we are letting the PUF data speak - what fraction of each record's weight should we use in order to hit the targets for the state? We would constrain that fraction so that it would be >= 0. Thus, we would never have negative weights, although zero weights might occur and might be desirable - some records drop out in some states. For example, suppose the file has a record with $50k agi and a $15k SALT deduction. If we knew where the records really came from (we don't), it might have been for some poor sucker in high-tax NY who is in the PUF sample. When we get around to targeting low-tax Mississippi, the method we use might use 0% of this record's weight, but it would never use a negative % of the weight - we wouldn't allow that.
The targets for each of the 50 states, by design, would be what we know (or believe) to be true for the 50 states. If we do a good job of hitting ALL of those targets, then by definition the sum of the values on our constructed file will equal the national totals, for all of the targeted variables, because the values for the states in https://www.irs.gov/statistics/soi-tax-stats-historic-table-2 add to the national total in that same source.
In other words, sums of targeted variables would equal known national totals. But that doesn't mean sums of calculated variables, such as federal tax under a different tax law, would equal the sum of same computed from the original file, although I suspect it would be close.
I think this would be an important check on our work and we would want, always, to investigate how close the totals are.

IPOPT claims no solution in the feasible region. Maybe I made a mistake somewhere, so I will work on it. Oddly, IPOPT doesn't seem to offer a way to look at the values for X after each step, or any way to look at G when execution terminates. So I have to jury-rig something.

I don't know if you've asked the Ipopt list; there may be an easy way to retrieve the X values at each step when you are calling Ipopt from a C++ or Fortran program, thus returning them to your program. An alternative might be to obtain them as output. Ipopt has an option, file_print_level, that controls the amount of output written to a file. It can range from 0 to 12, with a default of 5. I don't think the documentation says what you get at the different levels; the Ipopt mailing list might, or you might just experiment. I have to believe writing the X's would be included in one of the higher levels.
I, too, have wanted to retrieve the X's. When calling from R, the Ipoptr interface to Ipopt does not let you do that. What I have done - and you could easily do, too, is put a statement in your objective function (often called eval_f) that writes the then-current X values to an external file so you can watch how they change from step to step. That only took about 10 minutes of programming time for me.
I really hope we get to the point where the full recent (C++) version of Ipopt is working in multiple environments. As we've discussed, I can provide my Windows version to people with proper licenses, but it would be great to have it on Linux and Macs.

IPOPT claims no solution in the feasible region. Maybe I made a mistake somewhere, so I will work on it.

If you have not used the derivative checker, I strongly recommend using it, if you have any doubt at all about whether your derivative calculation is correct. I have found mistakes that way - I sent Ipopt looking for solutions to a feasible problem in directions where they could not be found.

On Sun, 24 Dec 2017, Don Boyd wrote:

  I see, we give up the requirement that the probabilities
  sum to 1 for each state. Same number of variables but far
  fewer constraints. That makes some sense as a
  simplification. Does it change the result? Do you get
  negative weights? I worry that the randomization of weight
  sums per record might
  affect the accuracy of the federal calculation. Do we use
  the SOI weight for the federal aggregates and our random
  weights for the state level aggregates? I think that works
  but do the states add up to the federal? Don't you get
  some negative weights? Doesn't that bother you?

If we do every state independently, we are letting the PUF data speak

what fraction of each record's weight should we use in order to hit
the targets for the state? We would constrain that fraction so that it
would be >= 0. Thus, we would never have negative weights, although
zero weights might occur and might be desirable - some records drop
out in some states. For example, suppose the file has a record with
$50k agi and a $15k SALT deduction. If we knew where the records
really came from (we don't), it might have been for some poor sucker
in high-tax NY who is in the PUF sample. When we get around to
targeting low-tax Mississippi, the method we use might use 0% of this
record's weight, but it would never use a negative % of the weight -
we wouldn't allow that.

The targets for each of the 50 states, by design, would be what we
know (or believe) to be true for the 50 states. If we do a good job of
hitting ALL of those targets, then by definition the sum of the values
on our constructed file will equal the national totals, for all of the
targeted variables, because the values for the states in
https://www.irs.gov/statistics/soi-tax-stats-historic-table-2 add to
the national total in that same source.
In other words, sums of targeted variables would equal known national
totals. But that doesn't mean sums of calculated variables, such as
federal tax under a different tax law, would equal the sum of same
computed from the original file, although I suspect it would be close.
I think this would be an important check on our work and we would
want, always, to investigate how close the totals are.

If we have 150,000 records and 40 constraints, there are obviously an
infinite number of solutions that meat the constraints. Your choice to
"use the distribution of weights that is most similar to the national
distribution that also meets the constraints" seems really plausible and
worthwhile, but I still worry about negative weights. I have to guess that
they are very rare, but even if that is true, I don't think it helps
matters to constrain to zero them ex post. Won't that bias the result away
from the know aggregate? Do you have any statistics on how often they
occur? If they are rare, shouldn't we leave them in? If the are common, we
should use another approach.
I am trying to puzzle out if the MaxEnt approach tends to make the states
look like the national distribution, and I think it does. But as you point
out there is considerable extra arithmetic with all those additional
constraints.
dan

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the
thread.[AHvQVWRf8lKN07ODCrU51E379oAyK83mks5tDjQugaJpZM4RLQP7.gif]

Forcing the weights to be non-negative doesn't bother me intellectually. I am not sure what would happen if we didn't force it. I think it depends on (a) how we establish the initial weights (for example, whether they are simply scaled down national weights, or something else), and (b) the objective function, and how much it penalizes changes from those initial weights. If we use a maximum entropy objective function, you could not get negative weights because you would have to have a negative x[i] and you can't take a log of a negative number. For some of the other objective functions under consideration, a negative x[i] is possible to have in the function, but the penalty would be huge.
So I don't know, 100%, but I doubt it would be an issue even if we constrained the x[i]'s and therefore the weights to non-negative numbers.
In all of the runs I have done, I have always constrained the x[i]'s to be nonnegative so I don't have any statistics on what happens if you relax that requirement. With maximum entropy, the problem would simply blow up if we tried to have negative values because of the can't-take-a-log-of-a-negative-number issue. That objective function tends to spread the x[i]'s out in (0, 1), with clustering in the 0.2 to 0.3 range I think. I don't think the other objective functions would want x[i] to be negative, generally.
As for bias caused by forcing the weights to be non-negative, I am not sure I understand the concern. The results will hit the known aggregates. If there are weights that the objective function wants to be negative, they will instead be zero - the associated, presumably weird, records will drop out.
My reaction is that we should start down the road and begin examining actual results. During the week I'll propose some next steps.

On Sun, 24 Dec 2017, Don Boyd wrote:

As for bias caused by forcing the weights to be non-negative, I am not sure I understand the concern.
The results will hit the known aggregates. If there are weights that the objective function wants to
be negative, they will instead be zero - the associated, presumably weird, records will drop out.

I am confused. Are you constraining the weights to be >0 during the
maximization, or are you accepting negative weights during maximization,
but setting them to zero when simulations are done. If the weights are
constrained to be >0, that adds a constraint for each taxpayer, which I
thought you wanted to avoid. You would have the same number of constraints
as MaxEnt, although they would be inequalities rather than equalities.
Does that make a difference? I have no idea if it is an important
difference - I have never done optimizations with inequality constraints.
I agree that there is no bias problem if the constraints are imposed
during maximization.
dan

During optimization. They are simply bounds on the variables. Not a
computational difficulty at all.
On Dec 25, 2017 7:20 AM, "Daniel Feenberg" notifications@github.com wrote:

On Sun, 24 Dec 2017, Don Boyd wrote:

As for bias caused by forcing the weights to be non-negative, I am not
sure I understand the concern.
The results will hit the known aggregates. If there are weights that the
objective function wants to
be negative, they will instead be zero - the associated, presumably
weird, records will drop out.

I am confused. Are you constraining the weights to be >0 during the
maximization, or are you accepting negative weights during maximization,
but setting them to zero when simulations are done. If the weights are
constrained to be >0, that adds a constraint for each taxpayer, which I
thought you wanted to avoid. You would have the same number of constraints
as MaxEnt, although they would be inequalities rather than equalities.
Does that make a difference? I have no idea if it is an important
difference - I have never done optimizations with inequality constraints.
I agree that there is no bias problem if the constraints are imposed
during maximization.
dan
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/open-source-economics/PUF-State-Distribution/issues/1#issuecomment-353865771,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGPEmHfO3Zb9srbJzUmV8mnScrJrSHITks5tD5L-gaJpZM4RLQP7
.

authors: MattHJensen donboyd5 feenberg

license: MIT


text:
OnOpampConnectionSettings/Accepted callbacks need re-thinking

The comments say that the Client implementation (the caller) will attempt to re-connect using new settings.
The example implementation works completely differently, the callback tries the re-connection.
Which is the right way?
To summarize this is what the example is supposed to do:

OnOpampConnectionSettings callback called when new settings are offered by the Server.
The callback implementation first pre-verifies the settings (e.g. check certificates, etc).
If checks in (2) pass the callback implementation logs that it is starting to reconnect, creates a reconnection goroutine and returns from the callback.
Reconnection goroutine stops the Client, creates a new Client with new connection settings and wait for successful OnConnect() callback.
If OnConnect() is not called within a predefined period of time reconnection goroutine assumes the new connection settings are bad, reverts to the old connection settings and re-creates the Client again.
We get rid of OnOpampConnectionSettingsAccepted(), it is not needed.

The example implementation of steps 4 and 5 is not complete today (e.g not waiting for OnConnect), but can be modified to match the above steps.
See also comment thread here: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/30237#discussion_r1509173487

cc @andykellr @srikanthccv @evan-bradley

I listened to the meeting recording, and this sounds good to me. However, making it non-blocking leaves us with one question: what would be the mechanism for the client to report back to the server whether it accepted or rejected the connection settings offer?

what would be the mechanism for the client to report back to the server whether it accepted or rejected the connection settings offer?

It can be done using a health message. We don't have any other way to report errors from the agent currently.

Steps 1-3 and 6 done in https://github.com/open-telemetry/opamp-go/pull/266
Steps 4-5 remaining.

authors: srikanthccv tigrannajaryan

repo: open-telemetry/opamp-go


text:
Merge changes from dd-trace-java 0.40.0

https://github.com/DataDog/dd-trace-java/releases/tag/v0.40.0

@trask sorry for the delay.  This is ready to review/merge now.


text:
Update otel-webserver-module for centos 9 stream, since centos7 is EOL

Centos7 has reached EOL, otel-webserver-module build and compatibility needs to be provided for the latest centos9 stream.

cc @DebajitDas

@lalitb
@aryanishan1001  is already working on this

Nginx SDK 1.26.0 with Redhat 8.9 version is not supported for this OS

authors: DebajitDas aryanishan1001 lalitb nrBaskar


text:
fix: observers should not expose bind/unbind method

Which problem is this PR solving?

Fixes #997

Short description of the changes

@opentelemetry/api: Add new interface UnboundMetric, with bind/unbind method, which extends Metric.
@opentelemetry/metrics: Removed problematic setCallback method from BoundObserver. BoundObsever now acts as merely an instrument hold values, should not be exposed as public API.

Codecov Report

Merging #1001 into master will decrease coverage by 0.56%.
The diff coverage is 87.50%.

@@            Coverage Diff             @@
##           master    #1001      +/-   ##
==========================================
- Coverage   95.00%   94.44%   -0.57%
==========================================
  Files         212      166      -46
  Lines        8805     6745    -2060
  Branches      796      662     -134
==========================================
- Hits         8365     6370    -1995
+ Misses        440      375      -65

Impacted Files
Coverage Δ

packages/opentelemetry-api/src/metrics/Metric.ts
100.00% <ø> (ø)

...ackages/opentelemetry-api/src/metrics/NoopMeter.ts
72.72% <87.50%> (ø)

...ry-tracing/test/export/SimpleSpanProcessor.test.ts

packages/opentelemetry-tracing/src/version.ts

...elemetry-tracing/src/export/SimpleSpanProcessor.ts

...lemetry-tracing/src/export/InMemorySpanExporter.ts

...es/opentelemetry-tracing/src/MultiSpanProcessor.ts

...s/opentelemetry-tracing/src/BasicTracerProvider.ts

...y-tracing/test/export/InMemorySpanExporter.test.ts

...ages/opentelemetry-metrics/src/MetricObservable.ts

... and 34 more

authors: codecov-io legendecas

repo: open-telemetry/opentelemetry-js


text:
Merge back into a single lerna monorepo

This is attempting to solve several pain points we've had which stem from the fact that our stable and experimental packages are not linked by lerna and aren't released together.
Keeping this as a draft for now

AFAICT, Lerna can only bump all changed packages to the same version -- this is not what we expect of stable packages and experimental packages release works. Is yarn workspace an available choice? I found that react is using yarn workspace and publishes packages with different versions (scheduler v0.21.0, and react v18.0.0) at one time.

AFAICT, Lerna can only bump all changed packages to the same version -- this is not what we expect of stable packages and experimental packages release works.

My current plan is to use lerna independent mode and to create automations to ensure the stable packages are versioned together and the experimental packages are versioned together.

Is yarn workspace an available choice? I found that react is using yarn workspace and publishes packages with different versions (scheduler v0.21.0, and react v18.0.0) at one time.

We considered yarn workspaces a long time ago and I can't remember exactly why it was rejected. I think it had to do with supporting old node versions but I could be wrong. NPM now also has workspace support but only for npm 7+.

My current plan is to use lerna independent mode and to create automations to ensure the stable packages are versioned together and the experimental packages are versioned together.

Oh, now I know lerna supports independent mode :O. This sounds great and may fit our use case.

@open-telemetry/javascript-approvers sorry for the delay but this is ready to be reviewed now. Its a lot of files changed but should be relatively easy to review.

I'm confused by the @opentelemetry/api version change. What benefit can we gain on that change?

The specification requires that an SDK support old API versions. This allows users to freely update their SDK without fear that dependencies which use an older API will break.

looks fine for lerna but i'm not sure to understand why we changed back to SpanAttributes instead of Attributes ? Is this to support TS user with latest SDK but API <1.1 ?

Yes

authors: dyladan legendecas


text:
feat: Add support for mutual TLS and improve SSL error logging.

Add support for specifying client certificate and key for mutual TLS when exporting.
Also log more information about why an SSL error occured as this can be very difficult to diagnose. This is logged in the same way as other probably fatal issues are, e.g. HTTP 404s.

@megabus-tobin Thank you for your contribution!
Please consider separating the error handling changes in a separate PR. We will be able to review and release that change independent of verifying the correctness of the changes required for mTLS support.
Happy Holidays!

@arielvalentin I've split the small logging change off into #1557

Could you incorporate the new environment variables into the exporter tests? (here's the file for the OTLP library)
Anywhere the certificate_file is mentioned may be a good place to add content for the client certificate and key.

The Net:HTTP class makes this a bit harder than it should be. Unlike ca_cert, the cert and key members aren't strings, they're OpenSSL::X509::Certificate and OpenSSL::PKey::RSA objects.
I'm not sure what the best approach would be. Should I add a test certificate and key to the repository or refactor OpenTelemetry::Exporter::OTLP::Exporter.initialize to optionally take the object directly and fallback to trying to load them from the environment?
The latter would be very similar to what OpenTelemetry::Exporter::OTLP::Exporter.prepare_endpoint already does. It would also have the small advantage of allowing for more exotic ways of obtaining the certificate and key but the utility of that is questionable since you need a file for the CA cert anyway.

The Net:HTTP class makes this a bit harder than it should be. Unlike ca_cert, the cert and key members aren't strings, they're OpenSSL::X509::Certificate and OpenSSL::PKey::RSA objects.
I'm not sure what the best approach would be. Should I add a test certificate and key to the repository or refactor OpenTelemetry::Exporter::OTLP::Exporter.initialize to optionally take the object directly and fallback to trying to load them from the environment?
The latter would be very similar to what OpenTelemetry::Exporter::OTLP::Exporter.prepare_endpoint already does. It would also have the small advantage of allowing for more exotic ways of obtaining the certificate and key but the utility of that is questionable since you need a file for the CA cert anyway.

Sorry for my delated response. Great questions! I think adding the test certificate and key seems the least intrusive to what you've already built if that's not too much effort. If other approvers/maintainers disagree, please chime in!
I like your idea about following the pattern in OpenTelemetry::Exporter::OTLP::Exporter.prepare_endpoint, but like you mentioned, I'm not sure about the utility of that approach.

@kaylareopelle I have updated the tests to check that the client certificate and key are handled correctly.
Some small notes:

To test that explicit TLS settings are preferred to environment variables I needed a second cert/key that would be loaded in the unlikely event the test was going to fail.
Initially I generated the cert/key on the fly but since a path is needed this would have made it necessary to ensure a writeable filesystem when running tests. Instead I have put the test certs/keys into the same directory as the tests and referenced that via __FILE__.
The certs/keys I generated are obviously meaningless. E.g. CN = a.example.tld, O = Internet Widgits Pty Ltd. By the time this gets reviewed they will probably also be expired, which the tests don't care about.
Rather than reading the certs/keys at the point of comparison, I've done it once near the top of the file. Apart from avoiding a little repetition this makes it much easier to spot if the files got removed, etc. rather than an individual test appearing to fail.

Would be nice to update the gRPC exporter as well.
creds = if mtls_config_provided
  GRPC::Core::ChannelCredentials.new(ca, key, cert)
else
  :this_channel_is_insecure
end

@client = Opentelemetry::Proto::Collector::Trace::V1::TraceService::Stub.new(
  "#{uri.host}:#{uri.port}",
  creds
)

https://github.com/open-telemetry/opentelemetry-ruby/blob/main/exporter/otlp-grpc/lib/opentelemetry/exporter/otlp/grpc/trace_exporter.rb#L34

@kaylareopelle I have updated the tests to check that the client certificate and key are handled correctly.

@megabus-tobin, thank you for updating the tests! I think this is a solid approach.
Are you planning to make the GRPC changes mentioned here as part of this PR?

@kaylareopelle

Are you planning to make the GRPC changes mentioned here as part of this PR?

I have made these changes now. I've only performed minimal testing on this as it's not something I've needed to use previously and am not familiar with it. Unlike the HTTP exporter, there are almost no existing tests included in the library.

We chatted about this PR in the SIG last week. A question was raised about whether other languages also have this feature.
The environment variables are referenced in the protocol exporter specification.
They were added in this PR: https://github.com/open-telemetry/opentelemetry-specification/pull/2370
The OTEL_EXPORTER_OTLP_CLIENT_KEY has been added to Go, PHP, and JS (search)
cc @mwear

The OTEL_EXPORTER_OTLP_CLIENT_KEY has been added to Go, PHP, and JS (search)

It's available in the Java SDK too but is configured differently (because Java). See https://opentelemetry.io/docs/languages/java/configuration/ and in particular the otel.exporter.otlp.client.key system property.

authors: arielvalentin kaylareopelle megabus-tobin szechyjs

repo: open-telemetry/opentelemetry-ruby

license_source: bigquery


text:
Merge the sdk-logs package into the active sandbox

Package name: @opentelemetry/sdk-logs
Source Location: auto-merge/js/experimental/packages/sdk-logs
Destination: pkgs/sdk-logs/

Completed with the linked PR's


text:
Update trace-receiver.md

Need to assign -p 14250:14250 otherwise connect Jaeger will be failed
It is necessary to rebuild when you modify components.go to supporting custom Receiver

@rquedas can you look at the suggested changes.
@noahdyp please make sure that you sign the CLA successfully, if you're a corporate contributor work with your internal OSS experts to get it signed, otherwise you can go with "individual contributor"

Are we still working on this ?.

@rahuldimri if you're interested in taking up this work, please feel free to submit another PR (that links to this one and gives credit) -- we can close this one due to inactivity in favor of yours if you do so.

@rahuldimri "It is necessary to rebuild when you modify components.go to supporting custom Receiver" in the context of the tutorial, you are in development mode, so building your code to see the change is implicit, not sure if we need to call it out.
@austinlparker  and @svrnm, what do you think

Sure thanks let me have a look into this.

Closing in favor of https://github.com/open-telemetry/opentelemetry.io/pull/1598

authors: cartermp noahdyp rahuldimri rquedas svrnm


text:
Auto link in stability table

Small improvement for the tables with the stability matrix: if the value is "Stable" or "Experimental" it will automatically link the definition in the spec like some of the pages are doing it already.

What will the change look like @svrnm? TIA

Details

Sure, compare the preview with the current docs on some of the languages where that table is used:
https://deploy-preview-1849--opentelemetry.netlify.app/docs/instrumentation/cpp/
vs
https://opentelemetry.io/docs/instrumentation/cpp/

authors: melbgirl svrnm


text:
[zh] Show Chinese homepage in production

Folks, I think that we're ready to launch the homepage 🚀 . It maybe look a bit strange given that we don't have any docs pages, but those should come soon :) ... and once they do, I'll implement a fallback to en pages (#4478)
Fixes #2402

Preview: https://deploy-preview-4477--opentelemetry.netlify.app/zh/
/cc @open-telemetry/docs-cn-approvers @jiekun

Awesome work everyone! Let's keep this rolling

https://opentelemetry.io/zh/ 🎉

authors: chalin svrnm


text:
fix(es-dev-server): don't look for config in root dir

As discussed in https://github.com/open-wc/open-wc/commit/4085898bf9fd23ab51cd86d5fe582191c30be64e#r36748834, we introduced a breaking change by looking in the root dir for a config. In hindsight, this change was not needed for achieving what we need so we should revert it.

@tmsns

repo: open-wc/open-wc


text:
Request to join pattern house

GitHub Username; Aztech07
I want to be a part of the organization in order to get knowledge about Open Source. I would like to contribute to your organization and learn new skills and have a good experience while learning and contributing to the project.
I would like to contribute the patterns in C++, because I'm quite comfortable in that.

sent an invite, let m eknow if you are a participant of the ongoing SWOC open source program or a normal contributor


text:
Roadmap to Specification

Collaboration

[x] Read Introduction to Git and GitHub
[x] Read Workflow for Contributing
[x] Read GitFlow Workflow
#002
#003
#004
#005
[x] Make yourself familiar with the Basic Syntax of Markdown
[x] Read Formulating Issues
[x] Read Formulating Commit and Merge Request Messages
[x] Read Management of Conflicts
[x] Read Avoiding Conflicts
#006

High Level Design
ServiceList

[x] Read Structure of Services
[x] Read Structure of ServiceNames
[x] Read Structure of Release Numbers
[x] Read Structure of UUIDs in general and for details about Servers and Clients
[x] Read Concept of ServiceList
[ ] #017

ProfileList

[x] Read Concept of Profiles
[x] Structure of UUIDs in general and for details about Profiles
[x] Read Concepts of ProfileList and ProfileInstanceList
[x] #018
[ ] #019

Note on ProfileList: no additional profiles needed for now -> no modification.
ProfileListInstances could be extended with additional action profiles.

authors: kmohr-soprasteria openBackhaul

repo: openBackhaul/MicroWaveDeviceInventory