Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Requirements”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 199 records · Page 11

IPL Processing of the Viking Orbiter Images of Mars

The Viking orbiter cameras returned over 9000 images of Mars during the 6-month nominal mission. Digital image processing was required to produce products suitable for quantitative and qualitative scientific interpretation. Processing included the production of surface elevation data using computer stereophotogrammetric techniques, crater classification based on geomorphological characteristics, and the generation of color products using multiple black-and-white images recorded through spectral filters. The Image Processing Laboratory of the Jet Propulsion Laboratory was responsible for the design, development, and application of the software required to produce these 'second-order' products.

Ruiz, R. M.↗

Towards Test Driven Development for Computational Science with pFUnit

Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.

pFUnit↗

Experimental land observing data system feasibility study

An end-to-end data system to support a Shuttle-based Multispectral Linear Array (MLA) mission in the mid-1980's was defined. The experimental Land Observing System (ELOS) is discussed. A ground system that exploits extensive assets from the LANDSAT-D Program to effectively meet the objectives of the ELOS Mission was defined. The goal of 10 meter pixel precision, the variety of data acquisition capabilities, and the use of Shuttle are key to the mission requirements, Ground mission management functions are met through the use of GSFC's Multi-Satellite Operations Control Center (MSOCC). The MLA Image Generation Facility (MIGF) combines major hardware elements from the Applications Development Data System (ADDS) facility and LANDSAT Assessment System (LAS) with a special purpose MLA interface unit. LANDSAT-D image processing techniques, adapted to MLA characteristics, form the basis for the use of existing software and the definition of new software required.

Buckley, J. L.↗

Display Developer for Firing Room Applications

The firing room at Kennedy Space Center (KSC) is responsible for all NASA human spaceflight launch operations, therefore it is vital that all displays within the firing room be properly tested, up-to-date, and user-friendly during a launch. The Ground Main Propulsion System (GMPS) requires a number of remote displays for Vehicle Integration and Launch (VIL) Operations at KSC. My project is to develop remote displays for the GMPS using the Display Services and Framework (DSF) editor. These remote displays will be based on model images provided by GMPS through PowerPoint. Using the DSF editor, the PowerPoint images can be recreated with active buttons associated with the correct Compact Unique Identifiers (CUIs). These displays will be documented in the Software Requirements and Design Specifications (SRDS) at the 90% GMPS Design Review. In the future, these remote displays will be available for other developers to improve, edit, or add on to so that the display may be incorporated into the firing room to be used for launches.

Firing Room Application↗

Modernizing the Legacy Fission Wire Measurement System for the Advanced Test Reactor-Critical Facility

Operational lifetime extensions of existing research reactors have emphasized the need for refurbishment, replacements, and upgrades to supporting equipment and instrumentation. The Advanced Test Reactor (ATR) at Idaho National Laboratory (INL), which entered service in 1967, has recently completed the sixth core internals change-out and has scheduled operations until at least 2040. Reactor maintenance and operational risk management is critically important in the research reactor community, however supporting measurement systems sometimes get overlooked when maintenance is planned. The Fission Wire Measurement System (FWMS) is a custom measurement system designed in the 1960s to measure the beta-particle activity of irradiated uranium-aluminum fission wires. This measurement is conducted to determine the fission rate profile of the Advanced Reactor Test Critical (ATR-C) facility. The ATR-C is an open-pool, low-power test reactor that was purpose driven to resemble ATR and is used to qualify experiment configurations and verify core models prior to full-power experiment irradiations in ATR. A power distribution measurement in ATR-C uses uranium-aluminum wires that are distributed throughout the ATR-C core to validate simulation and modeling results. These measurements require 340 to 1500 wires to be irradiated and measured within a 12-hour window. The activity of the wires is measured in the required time with the FWMS, which was put into service in 1965 at the Radiation Measurements Laboratory (RML). The system consists of 4 measurement channels and one reference channel, each with a 2-pi proportional gas flow detector and the measurement channels each have an automated sample changer. This legacy system is crucial to the continued operations of ATR and has undergone some minor hardware upgrades since 1965, however the system presently relies on custom control boards, custom gas ion chambers, analog amplifiers/discriminators, and a user interface (UI) for the system written in outdated code. Much of the equipment and software is custom with no commercial replacements or support and limited documentation. The existing control software requires an operating system that is no longer supported, creating more vulnerabilities to continued operations. A project is underway with a third-party vendor to design, build, and document a new control and data acquisition system (CDAS) for the FWMS. The new upgrade will replace the control system, computer, UI, sample changer motors, and main power supply while maintaining the interface with existing detector hardware. The upgraded system will be operated in parallel with the current hardware and software to conduct validation testing. This equipment upgrade demonstrates the commitment at ATR to ensuring successful operations and potential future research reactors at INL.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗

Desirable features of an infrared imaging system for aerodynamic research

Advantage of non-intrusiveness, capability for field measurement, and increased availability of IR imaging systems have resulted in their wider use for aerodynamic research. However, certain difficulties persist while using currently available systems for such applications. A critical evaluation of the IR imaging systems is presented on the basis of the state-of-the-art of IR imaging technology and experiences in wind tunnel and flight testing at NASA's Langley Research Center. The requirements for using IR thermography as a measurement tool in aerodynamic research are examined in terms of range, sensitivity, and accuracy of temperature measurement, temporal and spatial resolution, and features of target. Deficiencies of present IR imaging systems are identified, and user precautions to avoid such problems by proper selection and operation of these units are suggested. Different aspects of imager performance such as imager optics, video capabilities, and environmental tolerance are discussed. Electronic data recording and image processing hardware and software requirements are evaluated. Slit response tests and spatial resolution are discussed with the objective of obtaining reliable, accurate, and meaningful information from IR thermography measurements for aerodynamic studies.

Wright, Robert E., Jr.↗

Benefits and Challenges of CCSDS File Delivery Protocol as Applied to Europa Clipper

—This paper describes the use of the Consultative Committee for Space Data Systems (CCSDS) File Delivery Protocol (CFDP) on the Europa Clipper mission for both uplink and downlink of files. It includes an overview of CFDP, the history of why CFDP was chosen, how it benefits mission operations, some of the mission scenarios that stress CFDP, operability aspects, the best practices that Clipper adopted from other missions and some of the technical challenges with implementation, and verification and validation. The benefits to mission operations accrue because CFDP reduces the need for manual management of file transfer, including retransmission of missing data, and deletion of files only after confirmation of receipt by the ground. The challenges occur because CFDP is a round-trip protocol – it requires messages in both directions to complete a file transfer, and because it uses timers to ensure that control messages are resent if needed to prevent transactions from going stale. Any situations where communication is restricted to a single direction, interrupted, reordered, or backlogged can pose a challenge. There are also implementation challenges. Europa Clipper is the first mission at the Jet Propulsion Laboratory (JPL) to adopt class 2, fully acknowledged, CFDP for both uplink and downlink. The implementation needed new software, requirements and operational procedures. The experience of the Applied Physics Laboratory (APL) with CFDP from their previous missions was crucial to success for Europa Clipper. Because CFDP relies on timers and messages travel in both directions, verification and validation (V&V) requires new approaches. For certain scenarios, a live ground system talking to a live flight system with realistic simulated one-way light times, data rates and data outages must be used.

Albers, Joshua↗

Advanced Terrestrial Simulator (ATS) evaluation dataset at 7 catchments across the continental United States

This dataset comprises of the input files and other files required for Advanced Terrestrial Simulator (ATS) simulations at 7 catchments across the continental United States. ATS is an integrated surface-subsurface hydrology model. We include Jupyter notebooks (within scripts folder) for individual catchments showing information (including data sources, river network, soil, geology, landuse types etc.) on preparing the machine readable input files. ATS observation output files are provided in the output folder. Figures and analyses (.xlsx sheets) are also provided. The catchments include, Taylor River Upstream (Colorado); (b) Cossatot River (Arkansas); (c) Panther Creek (Alabama); (d) Little Tennessee River (North Carolina and Georgia); (e) Mayo River (Virginia); (f) Flat Brook (New Jersey); (g) Neversink River headwaters (New York). Readme files are provided inside the directories providing more details. Files types include: .xml, .h5, .xlsx, .png, .ipynb, .py, .nc, .txt. All of the files types can be accessed by open source software, details on software requirements are following: .xml (any text editors including notepad and textedit), .h5 (in python using hdf libraries), .xlsx (WPS Office Spreadsheets, OpenOffice Calc, LibreOffice Calc, Microsoft Office etc.), .png (any image viewer), .ipynb (Jupyter notebook), .py (any text editors including notepad and textedit), .nc (using python or other open source software).

54 ENVIRONMENTAL SCIENCES↗

Digital interactive image analysis by array processing

An attempt is made to draw a parallel between the existing geophysical data processing service industries and the emerging earth resources data support requirements. The relationship of seismic data analysis to ERTS data analysis is natural because in either case data is digitally recorded in the same format, resulting from remotely sensed energy which has been reflected, attenuated, shifted and degraded on its path from the source to the receiver. In the seismic case the energy is acoustic, ranging in frequencies from 10 to 75 cps, for which the lithosphere appears semi-transparent. In earth survey remote sensing through the atmosphere, visible and infrared frequency bands are being used. Yet the hardware and software required to process the magnetically recorded data from the two realms of inquiry are identical and similar, respectively. The resulting data products are similar.

Sabels, B. E.↗

Dynamic IT Security Database and Analytics for Launch Control Systems Software

During the Summer 2020 session, I worked with intern Destani S. Van Arsdalen of EGS Software. Together, we co-created a tool to aid the dynamic investigation, updated over time,of the security compliance of LCS COTS and open source software. We originally planned touse spreadsheet software for management and analysis, but through this exploratoryproject, chose to use Python and JSON after receiving feedback on our project’s current anddesired capabilities at that time.At first, the project was solely designed to help on-board new COTS software, based on aquestionnaire that could be filled out for each software package. This, combined with usingthe spreadsheet application’s web-query capabilities to fetch information from the NVD,allowed presentation and analytics cells to automatically populate as elements of themanually-filled questionnaire changed. While this system was promising, we decided tochange technologies for a few reasons. In the spreadsheet, single cells could not hold complexdata like arrays and objects. The automatic population of cells and dynamic updates made itdifficult to manage and add new features. And finally, it had limited extensibility sinceadding new software required significant understanding of how both the spreadsheet wasconstructed, and the more obscure, proprietary scripting languages packaged with it.The pivot to a standard computer science database language of JSON, aided by thescripting capabilities of Python, greatly helped to improve the project’s functionality. First,and most importantly, the script’s import and analysis of database data is easilyreproducible. Additional data analysis can be modularly added without requiringmodification of the script and is capable of routine scheduling. The revised process can besplit into three parts. First, the conversion of LCS asset and software documentation into theJSON hierarchical database format. Second, the merging of this database with the NVD,forming a new data structure, using CPEs of the CVE object as a linking element betweenthem. And third, the automatically performed analytics and analysis of the combined data,in a modular and extensible format, to produce better informed business decisions. The outputted graphs, for example, are automatically generated by the Python script inconnection with the combined database. This allows updated graphs and any analytics to be re-rendered automatically following updates to the LCS’s initial asset documentation. Afinal report can then be programmatically and easily constructed from these sources to allow fully reproducible metrics for heavily evidenced risk management decisions.

it↗

Using Multiplicative Algebraic Reconstruction Techniques (MART) to Derive Instrument Requirements for Computed Tomography Imaging Spectrographs

Computed Tomography Imaging Spectrographs (CTISs), which are generally slitless or large-aperture spectrographs that observe a wide, dispersed field of view in multiple dispersion angles or diffraction orders, provide a unique opportunity to capture spectral information over an extended source, such as the Sun, but require software reconstruction techniques to be fully utilized. A useful data product that can be recovered from CTIS observations is intensity maps of solar features in single spectral lines. These intensity maps can then be used to determine temperature, density, abundance, and equilibrium properties of the emitting plasma. We apply the multiplicative algebraic reconstruction technique (MART) to example data from a variety of CTIS configurations to determine the capability and limitations of the method to return spectrally-pure maps. By completing this study, we aim to establish a path to derive requirements for CTIS instruments that rely on reconstruction techniques to meet their science objectives.

Amy Winebarger↗

CMS Experience with Adoption of the Community supported DD4hep Toolkit

DD4hep is an open-source software toolkit that provides comprehensive and complete generic detector descriptions for high energy physics (HEP) detectors. The Compact Muon Solenoid collaboration (CMS) has recently evaluated and adopted DD4hep to replace its custom detector description software. CMS has demanding software requirements as a very large, longrunning experiment that must support legacy geometries and study many possible upgraded detector designs of a constantly evolving detector that will be taking data for many years to come. CMS has chosen DD4hep since it is a high-quality, community-supported solution that will benefit from continuing modernization and maintenance. This presentation will discuss the issues of DD4hep adoption, the advantages and disadvantages of the various design choices, performance results, and the integration of the plugin systems from CMS and Gaudi, another open-source software framework. Recommendations about DD4hep based upon the CMS use cases will also be presented.

Vuosalo, Carl↗

Automated Processing of ISIS Topside Ionograms into Electron Density Profiles

Modeling of the topside ionosphere has for the most part relied on just a few years of data from topside sounder satellites. The widely used Bent et al. (1972) model, for example, is based on only 50,000 Alouette 1 profiles. The International Reference Ionosphere (IRI) (Bilitza, 1990, 2001) uses an analytical description of the graphs and tables provided by Bent et al. (1972). The Alouette 1, 2 and ISIS 1, 2 topside sounder satellites of the sixties and seventies were ahead of their times in terms of the sheer volume of data obtained and in terms of the computer and software requirements for data analysis. As a result, only a small percentage of the collected topside ionograms was converted into electron density profiles. Recently, a NASA-funded data restoration project has undertaken and is continuing the process of digitizing the Alouette/ISIS ionograms from the analog 7-track tapes. Our project involves the automated processing of these digital ionograms into electron density profiles. The project accomplished a set of important goals that will have a major impact on understanding and modeling of the topside ionosphere: (1) The TOPside Ionogram Scaling and True height inversion (TOPIST) software was developed for the automated scaling and inversion of topside ionograms. (2) The TOPIST software was applied to the over 300,000 ISIS-2 topside ionograms that had been digitized in the fkamework of a separate AISRP project (PI: R.F. Benson). (3) The new TOPIST-produced database of global electron density profiles for the topside ionosphere were made publicly available through NASA s National Space Science Data Center (NSSDC) ftp archive at . (4) Earlier Alouette 1,2 and ISIS 1, 2 data sets of electron density profiles from manual scaling of selected sets of ionograms were converted fiom a highly-compressed binary format into a user-friendly ASCII format and made publicly available through nssdcftp.gsfc.nasa.gov. The new database for the topside ionosphere established as a result of this project, has stimulated a multitude of new studies directed towards a better description and prediction of the topside ionosphere. Marinov et al. (2004) developed a new model for the upper ion transition height (Oxygen to Hydrogen and Helium) and Bilitza (2004) deduced a correction term for the I N topside electron density model. Kutiev et al. (2005) used this data to develop a new model for the topside ionosphere scale height (TISH) as a function of month, local time, latitude, longitude and solar flux F10.7. Comparisons by Belehaki et al. (2005) show that TISH is in general agreement with scale heights deduced from ground ionosondes but the model predicts post-midnight and afternoon maxima whereas the ionosonde data show a noon maximum. Webb and Benson (2005) reported on their effort to deduce changes in the plasma temperature and ion composition from changes in the topside electron density profile as recorded by topside sounders. Limitations and possible improvements of the IRI topside model were discussed by Coisson et al. (2005) including also the possible use of the NeQuick model, Our project progressed in close collaboration and coordination with the GSFC team involved in the ISIS digitization effort. The digitization project was highly successful producing a large amount of digital topside ionograms. Several no-cost extensions of the TOPIST project were necessary to keep up with the pace and volume of the digitization effort.

Reinisch, bodo W.↗

Space Station needs, attributes and architectural options. Volume 2, book 2, part 2, Task 2: Information management system

Missions to be performed, station operations and functions to be carried out, and technologies anticipated during the time frame of the space station were examined in order to determine the scope of the overall information management system for the space station. This system comprises: (1) the data management system which includes onboard computer related hardware and software required to assume and exercise control of all activities performed on the station; (2) the communication system for both internal and external communications; and (3) the ground segment. Techniques used to examine the information system from a functional and performance point of view are described as well as the analyses performed to derive the architecture of both the onboard data management system and the system for internal and external communications. These architectures are then used to generate a conceptual design of the onboard elements in order to determine the physical parameters (size/weight/power) of the hardware and software. The ground segment elements are summarized.

Source record↗

Enhancing the Quality and Reliability of Machine Learning Interatomic Potentials through Better Reporting Practices

Recent developments in machine learning interatomic potentials (MLIPs) have empowered even nonexperts in machine learning to train MLIPs for accelerating materials simulations. However, reproducibility and independent evaluation of presented MLIP results is hindered by a lack of clear standards in current literature. In this Perspective, we aim to provide guidance on best practices for documenting MLIP use while walking the reader through the development and deployment of MLIPs including hardware and software requirements, generating training data, training models, validating predictions, and MLIP inference. We also suggest useful plotting practices and analyses to validate and boost confidence in the deployed models. Finally, we provide a step-by-step checklist for practitioners to use directly before publication to standardize the information to be reported. Altogether, we hope that our work will encourage the reliable and reproducible use of these MLIPs, which will accelerate their ability to make a positive impact in various disciplines including materials science, chemistry, and biology, among others.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

Team Training and Retention of Skills Acquired Above Real Time Training on a Flight Simulator

Above Real-Time Training (ARTT) is the training acquired on a real time simulator when it is modified to present events at a faster pace than normal. The experiments related to training of pilots performed by NASA engineers (Kolf in 1973, Hoey in 1976) and others (Guckenberger, Crane and their associates in the nineties) have shown that in comparison with the real time training (RTT), ARTT provides the following benefits: increased rate of skill acquisition, reduced simulator and aircraft training time, and more effective training for emergency procedures. Two sets of experiments have been performed; they are reported in professional conferences and the respective papers are included in this report. The retention of effects of ARTT has been studied in the first set of experiments and the use of ARTT as top-off training has been examined in the second set of experiments. In ARTT, the pace of events was 1.5 times the pace in RTT. In both sets of experiments, university students were trained to perform an aerial gunnery task. The training unit was equipped with a joystick and a throttle. The student acted as a nose gunner in a hypothetical two place attack aircraft. The flight simulation software was installed on a Universal Distributed Interactive Simulator platform supplied by ECC International of Orlando, Florida. In the first set of experiments, two training programs RTT or ART7 were used. Students were then tested in real time on more demanding scenarios: either immediately after training or two days later. The effects of ARTT did not decrease over a two day retention interval and ARTT was more time efficient than real time training. Therefore, equal test performance could be achieved with less clock-time spent in the simulator. In the second set of experiments three training programs RTT or ARTT or RARTT, were used. In RTT, students received 36 minutes of real time training. In ARTT, students received 36 minutes of above real time training. In RARTT, students received 18 minutes of real time training and 18 minutes of above real time training as top-off training. Students were then tested in real time on more demanding scenarios. The use of ARTT as top-off training after RTT offered better training than RTT alone or ARTT alone. It is, however, suggested that a similar experiment be conducted on a relatively more complex task with a larger sample of participants. Within the proposed duration of the research effort, the setting up of experiments and trial runs on using ARTT for team training were also scheduled but they could not be accomplished due to extra ordinary challenges faced in developing the required software configuration. Team training is, however, scheduled in a future study sponsored by NASA at Tuskegee University.

Ali, Syed Friasat↗

Science opportunity analyzer - a multi-mission tool for planning

For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.

SOA science planning mission operations sequence s↗

Editorial: Neuroscience, computing, performance, and benchmarks: Why it matters to neuroscience how fast we can compute

At the turn of the millennium the computational neuroscience community realized that neuroscience was in a software crisis: software development was no longer progressing as expected and reproducibility declined. The International Neuroinformatics Coordinating Facility (INCF) was inaugurated in 2007 as an initiative to improve this situation. The INCF has since pursued its mission to help the development of standards and best practices. In a community paper published this very same year, Brette et al. tried to assess the state of the field and to establish a scientific approach to simulation technology, addressing foundational topics, such as which simulation schemes are best suited for the types of models we see in neuroscience. In 2015, a Frontiers Research Topic “Python in neuroscience” by Muller et al. triggered and documented a revolution in the neuroscience community, namely in the usage of the scripting language Python as a common language for interfacing with simulation codes and connecting between applications. The review by Einevoll et al. documented that simulation tools have since further matured and become reliable research instruments used by many scientific groups for their respective questions. Open source and community standard simulators today allow research groups to focus on their scientific questions and leave the details of the computational work to the community of simulator developers. A parallel development has occurred, which has been barely visible in neuroscientific circles beyond the community of simulator developers: Supercomputers used for large and complex scientific calculations have increased their performance from ~10 TeraFLOPS (10 13 floating point operations per second) in the early 2000s to above 1 ExaFLOPS (10 18 floating point operations per second) in the year 2022. This represents a 100,000-fold increase in our computational capabilities, or almost 17 doublings of computational capability in 22 years. Moore's law (the observation that it is economically viable to double the number of transistors in an integrated circuit every other 18–24 months) explains a part of this; our ability and willingness to build and operate physically larger computers, explains another part. It should be clear, however, that such a technological advancement requires software adaptations and under the hood, simulators had to reinvent themselves and change substantially to embrace this technological opportunity. It actually is quite remarkable that—apart from the change in semantics for the parallelization—this has mostly happened without the users knowing. The current Research Topic was motivated by the wish to assemble an update on the state of neuroscientific software (mostly simulators) in 2022, to assess whether we can see more clearly which scientific questions can (or cannot) be asked due to our increased capability of simulation, and also to anticipate whether and for how long we can expect this increase of computational capabilities to continue.

biophysically detailed models↗