alabamaasrl / asset_asrl Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://alabamaasrl.github.io/asset_asrl/
License: Apache License 2.0
Home Page: https://alabamaasrl.github.io/asset_asrl/
License: Apache License 2.0
We need to implement better control switch detection and refinement for bang-bang problems. The new mesh refinement scheme does a pretty good job at making accurate meshes with minimal segments and works well on smooth control profiles. However, the drawback is that it can make bang-bang control profiles less well defined unless you use a very tight mesh tolerance. This is especially true with the BlockConstant control parameterization.
Looking to add at least two methods for switch detection. One will just look for sudden changes in individual components in the controls. The other will feed the states and estimated costates to a user defined indirect switching function and find its zeros. We will then let the mesh spacing float in the vicinity of the switches so that the optimizer can adjust the control profile accordingly.
I'll start prototyping this. If anybody has any suggestions, ideas, or requests let me know.
I'm seeing silent death for certain scripts running windows binaries recently uploaded to PyPi (version 0.4.0 and 0.5.0). Binaries compiled from source locally on windows have no issues and neither do any linux binaries hosted on PyPi.
We should have a set of benchmarks (probably using google benchmark) to use as a standard for regression-testing future developments. Results should be published in the docs and alongside releases.
This development work could also lead towards a unit-test suite.
Pardiso interface fails to compile on Windows with the following error:
[build] src\Solvers\PardisoInterface.h:40:17: error: cannot initialize a parameter of type 'const long long *' with an rvalue of type 'int *'
[build] 40 | pt, &maxfct, &mnum, &type, &phase, &n, a, ia, ja, perm, &nrhs, iparm, &msglvl, b, x, &error);
[build] | ^~~~~~~
[build] src\Solvers\PardisoInterface.h:193:55: note: in instantiation of member function 'Eigen::internal::pardiso_run_selector<int>::run' requested here
[build] 193 | internal::pardiso_run_selector<StorageIndex>::run(m_pt,
[build] | ^
[build] src\Solvers\PardisoInterface.h:135:7: note: in instantiation of member function 'Eigen::PardisoImpl<Eigen::PardisoLDLT<Eigen::SparseMatrix<double, 1>>>::pardisoRelease' requested here
[build] 135 | pardisoRelease();
[build] | ^
[build] src\Solvers\PardisoInterface.h:679:9: note: in instantiation of member function 'Eigen::PardisoImpl<Eigen::PardisoLDLT<Eigen::SparseMatrix<double, 1>>>::~PardisoImpl' requested here
[build] 679 | class PardisoLDLT : public PardisoImpl<PardisoLDLT<MatrixType, Options>> {
[build] | ^
[build] C:/Program Files (x86)/Intel/oneAPI/mkl/latest/include\mkl_pardiso.h:33:52: note: passing argument to parameter 'maxfct' here
[build] 33 | void pardiso( _MKL_DSS_HANDLE_t pt, const MKL_INT *maxfct, const MKL_INT *mnum,
[build] | ^
[build] 4 warnings and 1 error generated.
MKL Versions attempted:
Compilers attempted:
The internal type MKL_INT
is probably being set to long long int
rather than int
, causing the arguments to ::pardiso
to be const long long int *
rather than const int *
. Seems to be triggered by the MKL_ILP64
preprocessor definition.
We need better introspection capabilities into the operations of the optimizer. This will help users understand why their problem may be poorly formed and identify errors in their dynamics, constraints, and objectives.
I've had good experiences with spdlog, and I can copy over some utilities I've written for other projects to help get started.
Related to #26
There is interest in measuring PSIOPT's performance on the CUTEr/CUTEst set of optimization problems.
https://en.wikipedia.org/wiki/CUTEr
https://github.com/ralna/CUTEst
Log files are nice, but they require a parser to extract relevant data. Also, the fidelity of the data can be impacted by the choice of precision when doing string conversions. If we use a binary format like HDF5, we can avoid loss of precision.
In my opinion HDF5 is absolutely awful to work with in C++, but you can write a handful of utility functions that make it workable at least. Open to alternatives.
At present, we support interpolating tabular data defined on 1 and 2 dimensional grids. We should add support for N-dimensional grids.
This should probably be done as two new separate classes for 3-d and N-d grids. I'd imagine that there is a cleaner/more efficient algorithm for the 3d case that would merit a standalone implementation, and that we could get out the door quicker. @jdsikes1 , this aligns with your current work so you get this one.
First issue!
When installing via VS code/CMake, it could not locate MKL libraries eventhough they have been installed (via previous instructions) and have been properly sourced.
Is there a command/area of the cmake that can be hot-wired so that cmake can find it?
It appears that we are currently incompatible with numpy 2.0. I'm getting silent death on any script where a numpy array or list crosses the python-C++ boundary. Anybody getting this issue should remain on numpy <2 for now. I'm assuming that this is due to the older version of pybind11 we are currently tagged to. I'll update the submodule and see if it fixes the issue.
Any time an error is thrown as a result of evaluating a conditional, the arguments to the conditional should be embedded in the error message.
Add full code listing at end of all tutorial pages for users that want to copy the entire script and run right away
Putting this here, unless ASRL has a different issue tracking system you want to use.
Dockerfile should be enhanced for the following:
Currently Dockerfile only supports linux/amd64
architectures. Limiting factor is a Miniconda installation specifically for x64 architecture:
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-py39_22.11.1-1-Linux-x86_64.sh \
&& bash Miniconda3-py39_22.11.1-1-Linux-x86_64.sh -b -p /opt/miniconda3 \
&& ...
Some research is required to see if Dockerfile can be created for different architectures.
In ASSET build step, CPU count is currently hard-coded:
&& ...
&& cd build/ \
&& cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=true .. \
&& cmake --build . -j4 \
&& cd / \
&& ...
ASRL should make a Docker Hub account/repository and push Docker images to that account.
In my opinion, we have to have some kind of consistent formatting and style in order to be taken seriously. I have a .clang-format
configuration that I like (posted below). We don't have to use that, but I really do think we need something.
---
BasedOnStyle: Google
SortIncludes: true
ColumnLimit: 110
################################################################################
AccessModifierOffset: -1
AlignAfterOpenBracket: Align
# AlignArrayOfStructures: true
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: true
AlignConsecutiveMacros: true
AlignEscapedNewlines: Left
AlignTrailingComments: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortEnumsOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
AllowShortIfStatementsOnASingleLine: false
AllowShortLambdasOnASingleLine: true
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: Yes
BinPackArguments: false
BinPackParameters: false
BreakBeforeBinaryOperators: NonAssignment
BreakBeforeBraces: Attach
BreakBeforeTernaryOperators: true
BreakConstructorInitializers: BeforeColon
# BreakInheritanceList: AfterComma
BreakStringLiterals: true
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 4
# EmptyLineAfterAccessModifier: Leave
# EmptyLineBeforeAccessModifier: Always
FixNamespaceComments: true
IncludeBlocks: Regroup
# IndentAccessModifiers: true
IndentCaseBlocks: false
IndentCaseLabels: true
IndentPPDirectives: BeforeHash
# IndentRequires: true
IndentWidth: 2
IndentWrappedFunctionNames: true
# InsertTrailingCommas: true
KeepEmptyLinesAtTheStartOfBlocks: true
MaxEmptyLinesToKeep: 2
NamespaceIndentation: None
# PPIndentWidth: -1
# PackConstructorInitializers: NextLine
PointerAlignment: Left
# QualifierAlignment: Left
# QualifierOrder: ['inline', 'static', 'type', 'const', 'volatile']
# ReferenceAlignment: Pointer
ReflowComments: true
SortUsingDeclarations: true
SpaceAfterCStyleCast: true
SpaceAfterLogicalNot: false
SpaceAfterTemplateKeyword: false
# SpaceAroundPointerQualifiers: Default
SpaceBeforeAssignmentOperators: true
# SpaceBeforeCaseColon: false
SpaceBeforeCpp11BracedList: true
SpaceBeforeCtorInitializerColon: true
SpaceBeforeInheritanceColon: true
SpaceBeforeParens: ControlStatements
SpaceBeforeRangeBasedForLoopColon: false
SpaceBeforeSquareBrackets: false
SpaceInEmptyBlock: false
SpacesBeforeTrailingComments: 2
SpacesInAngles: false
SpacesInCStyleCastParentheses: false
SpacesInConditionalStatement: false
SpacesInContainerLiterals: false
# SpacesInLineCommentPrefix:
# Minimum: 1
# Maximum: 1
SpacesInParentheses: false
SpacesInSquareBrackets: false
Standard: c++17
TabWidth: 4
UseCRLF: false
UseTab: Never
ASSET libraries and package should be able to be installed with:
conda install -c <channel> asset_asrl
Or:
pip install asset_asrl
It would be unbelievably nice to use the core objects in other projects without being married to the Python bindings.
A potential refactor could look something like:
// Current
template<class Stuff>
struct Thing {
// Blah...
static void Build(py::module& m, const char* name) {
auto obj = py::class_<Thing<Stuff>>(m, name);
// more stuff
Base::DenseBaseBuild(obj);
};
static void BuildThings(py::module& m) {
Thing<Wow>::Build(m, "ThingWow");
Thing<Fake>::Build(m, "ThingFake");
}
becomes
// Proposed
#include "Thing.h"
#include "BuildDenseBase.h"
template<class Stuff>
static void BuildThing(py::module& m, const char* name) {
auto obj = py::class_<Thing<Stuff>>(m, name);
// You already know
BuildDenseBase<Thing<Stuff>>(obj);
}
static void BuildThings(py::module& m) {
BuildThing<Wow>(m, "ThingWow");
BuildThing<Fake>(m, "ThingFake");
}
This way, you'd have a totally separate folder (I like calling it bind
) that only contains a bunch of these BuildWhatever
functions. The core implementations wouldn't know about the bindings at all.
Really just flipping it all inside-out.
Adding example libraries to a different repo will allow for minimalist installation of ASSET without example scripts if not needed. Will help eventually with:
Intel has reorganized the internal layout of their libraries with version 2024.0. This appears to have borked our build system on linux. Looks like it can still find mkllibs but not OpenMP.
Host OS: WSL2
Running docker build -t asset .
on Dockerfile, steps 6 of 7 build successfully, but the last does not:
Step 7/7 : RUN . /root/.bashrc && export CC=/usr/bin/clang-15 && export CXX=/usr/bin/clang++-15 && export MKLROOT=/opt/miniconda3/envs/asset && git clone https://github.com/AlabamaASRL/asset_asrl.git && cd asset_asrl && git submodule update --init --recursive && mkdir build && cd build/ && cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=true .. && cmake --build . -j4 && cd / && rm -rf /asset_asrl
---> Running in ad68496de0a6
/bin/sh: 13: /root/.bashrc: shopt: not found
/bin/sh: 21: /root/.bashrc: shopt: not found
Cloning into 'asset_asrl'...
Submodule 'dep/eigen' (https://gitlab.com/wgledbetter/eigen.git) registered for path 'dep/eigen'
Submodule 'dep/fmt' (https://github.com/fmtlib/fmt.git) registered for path 'dep/fmt'
Submodule 'dep/pybind11' (https://github.com/pybind/pybind11.git) registered for path 'dep/pybind11'
Cloning into '/asset_asrl/dep/eigen'...
Cloning into '/asset_asrl/dep/fmt'...
Cloning into '/asset_asrl/dep/pybind11'...
Submodule path 'dep/eigen': checked out '5d33c67444ec8c49c01d3ca9de9be25f9e1f635c'
Submodule path 'dep/fmt': checked out 'fd41110d383b7240231718f009b21498e3984ccc'
Submodule path 'dep/pybind11': checked out '2d59b43cbf8793119fb92726ce8eb33441469e3e'
-- The CXX compiler identification is Clang 15.0.6
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++-15 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- pybind11 v2.11.0 dev1
-- Found PythonInterp: /opt/miniconda3/envs/asset/bin/python (found suitable version "3.9.15", minimum required is "3.6")
-- Found PythonLibs: /opt/miniconda3/envs/asset/lib/libpython3.9.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Performing Test HAS_FLTO_THIN
-- Performing Test HAS_FLTO_THIN - Success
-- Module support is disabled.
-- Version: 9.0.0
-- Build type: Release
-- CXX_STANDARD: 17
-- Performing Test has_std_17_flag
-- Performing Test has_std_17_flag - Success
-- Performing Test has_std_1z_flag
-- Performing Test has_std_1z_flag - Success
-- Required features: cxx_variadic_templates
-- Performing Test HAS_NULLPTR_WARNING
-- Performing Test HAS_NULLPTR_WARNING - Success
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- libiomp5.so
-- MKL_INTERFACE_LIBRARY = /opt/miniconda3/envs/asset/lib/libmkl_intel_lp64.so
-- MKL_SEQTHR_LIBRARY = /opt/miniconda3/envs/asset/lib/libmkl_intel_thread.so
-- MKL_CORE_LIBRARY = /opt/miniconda3/envs/asset/lib/libmkl_core.so
-- MKL_TBB_LIBRARY =
-- MKL_OMP_LIBRARY = /usr/lib/x86_64-linux-gnu/libiomp5.so
-- Found MKL: /opt/miniconda3/envs/asset/lib/libmkl_intel_lp64.so;/opt/miniconda3/envs/asset/lib/libmkl_intel_thread.so;/opt/miniconda3/envs/asset/lib/libmkl_core.so;/usr/lib/x86_64-linux-gnu/libiomp5.so
-- Found Python: /opt/miniconda3/envs/asset/bin/python3.9 (found version "3.9.15") found components: Interpreter Development Development.Module Development.Embed
-- ASSET will be installed to /root/.local/lib/python3.9/site-packages
-- CMAKE DIR LOC/asset_asrl
--
--
-- CMAKE DIR LOC/asset_asrl/src
-- CMAKE PROJ LOC/asset_asrl
-- Cleaning pyasset install directory
-- Configuring done
-- Generating done
-- Build files have been written to: /asset_asrl/build
[ 4%] Building CXX object dep/fmt/CMakeFiles/fmt.dir/src/format.cc.o
[ 6%] Building CXX object src/CMakeFiles/psiopt.dir/Solvers/PSIOPT.cpp.o
[ 4%] Building CXX object src/CMakeFiles/pch.dir/cmake_pch.hxx.pch
[ 8%] Building CXX object src/CMakeFiles/utils.dir/Utils/ColorText.cpp.o
[ 10%] Building CXX object dep/fmt/CMakeFiles/fmt.dir/src/os.cc.o
[ 12%] Building CXX object src/CMakeFiles/utils.dir/Utils/GetCoreCount.cpp.o
[ 14%] Building CXX object src/CMakeFiles/utils.dir/Utils/MemoryManagement.cpp.o
[ 16%] Building CXX object src/CMakeFiles/pch.dir/pch.cpp.o
[ 18%] Linking CXX shared library libfmt.so
[ 18%] Built target fmt
Cleaning asset_asrl install directory
Copied asset_asrl to /root/.local/lib/python3.9/site-packages
[ 18%] Built target pyassetsrc
[ 20%] Building CXX object src/CMakeFiles/psiopt.dir/Solvers/NonLinearProgram.cpp.o
[ 22%] Linking CXX static library libpch.a
[ 22%] Built target pch
[ 25%] Building CXX object src/CMakeFiles/vectorfunctions.dir/VectorFunctions/ASSET_VectorFunctions.cpp.o
[ 27%] Linking CXX static library libutils.a
[ 27%] Built target utils
[ 29%] Building CXX object src/CMakeFiles/optimalcontrol.dir/OptimalControl/ASSET_OptimalControl.cpp.o
[ 31%] Building CXX object src/CMakeFiles/psiopt.dir/Solvers/Jet.cpp.o
[ 33%] Building CXX object src/CMakeFiles/psiopt.dir/Solvers/OptimizationProblemBase.cpp.o
[ 35%] Building CXX object src/CMakeFiles/psiopt.dir/Solvers/OptimizationProblem.cpp.o
[ 37%] Building CXX object src/CMakeFiles/optimalcontrol.dir/OptimalControl/ODEPhaseBase.cpp.o
/asset_asrl/src/OptimalControl/ODEPhaseBase.cpp:671:3: warning: non-void lambda does not return a value in all control paths [-Wreturn-type]
};
^
[ 39%] Linking CXX static library libpsiopt.a
[ 39%] Built target psiopt
[ 41%] Building CXX object src/CMakeFiles/astro.dir/Astro/ASSET_Astro.cpp.o
Killed
gmake[2]: *** [src/CMakeFiles/optimalcontrol.dir/build.make:94: src/CMakeFiles/optimalcontrol.dir/OptimalControl/ODEPhaseBase.cpp.o] Error 137
gmake[2]: *** Waiting for unfinished jobs....
[ 43%] Building CXX object src/CMakeFiles/vectorfunctions.dir/VectorFunctions/VectorFunctionBuildPart1.cpp.o
Killed
gmake[2]: *** [src/CMakeFiles/astro.dir/build.make:78: src/CMakeFiles/astro.dir/Astro/ASSET_Astro.cpp.o] Error 137
gmake[1]: *** [CMakeFiles/Makefile2:400: src/CMakeFiles/astro.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 45%] Building CXX object src/CMakeFiles/vectorfunctions.dir/VectorFunctions/VectorFunctionBuildPart2.cpp.o
gmake[1]: *** [CMakeFiles/Makefile2:322: src/CMakeFiles/optimalcontrol.dir/all] Error 2
[ 47%] Building CXX object src/CMakeFiles/vectorfunctions.dir/VectorFunctions/ArgsSegBuildPart1.cpp.o
Killed
gmake[2]: *** [src/CMakeFiles/vectorfunctions.dir/build.make:110: src/CMakeFiles/vectorfunctions.dir/VectorFunctions/VectorFunctionBuildPart2.cpp.o] Error 137
gmake[2]: *** Waiting for unfinished jobs....
gmake[1]: *** [CMakeFiles/Makefile2:296: src/CMakeFiles/vectorfunctions.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2
The command '/bin/sh -c . /root/.bashrc && export CC=/usr/bin/clang-15 && export CXX=/usr/bin/clang++-15 && export MKLROOT=/opt/miniconda3/envs/asset && git clone https://github.com/AlabamaASRL/asset_asrl.git && cd asset_asrl && git submodule update --init --recursive && mkdir build && cd build/ && cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=true .. && cmake --build . -j4 && cd / && rm -rf /asset_asrl' returned a non-zero code: 2
I'm not sure why ASSET_Astro.cpp.o
fails to build.
I know this isn't a high priority, and I'm playing around with this as an academic curiosity (I mainly will be running asset on linux anyways).
I've followed the linux install docs and so far so good (with a couple of intellectual jumps for those familiar with Macs etc).
I end up with the following compiler error:
[build] clang: error: the clang compiler does not support '-march=native'
Since I'm not very familiar with compiling Asset, I figured I'd document this. Especially if it's an easy fix.
This isn't a priority so no need to rush to respond (unless you're bored :D)
For the installation instructions, there seems to be a couple of compiler configuration steps that need to be made explicit when configuring VS Code for the first time (linux instructions). They aren't that hard to figure out, but in order to be more explicit :D
(Blame Aaron).
As discussed in #25, we should add in the ability to retrieve the constraint violations for the transcriptions defects and user defined constraints, so its easier to diagnose issues with problem formulation/scaling etc.
We need to implement closed loop automatic mesh refinement for phases. Current error equilibration method is flakey and users cannot specify a desired mesh tolerance.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.