dataesr/scientific-paragraphs-categorization huggingface dataset:
The StrAx1. 0 software developed in Melbourne shows some promise in estimating porosity using clinical CT scan images. It automatically selects attenuation profile curves and segments the bone into trabecular, transitional and compact cortical bone. Using this software and low resolution clinical CT (voxel size 740 μm), they found that cortical porosity was associated with non-vertebral fracture risk, independent of bone mineral density  56, 57. In our study, we used high resolution micro-CT to image the pores in cortical bone. A previous synchrotron CT study that measured cortical porosity  58  had a similar pixel size to our study (7. 5 μm compared to 7 μm in our study). Currey and Shahar classified cortical porosity according to five levels, from large to small: Level 1 is classified as the marrow cavity, level 2 is the level for nutrient arteries, level 3 is the vascular porosity, level 4 is the lacuna-canicular porosity and level 5 is the nanoporosity  59.
The bone was modelled as 6 mm in height, the height of the samples in the study, using ANSYS software (ANSYS, Canonsburg, USA). The modelling was performed using half the indenter tip and half the bone to simplify the analysis (Fig. S3 , Supplementary Materials 4). Three sample widths were chosen: 3 mm which was equivalent to the dimensions of the samples, 30 mm and 60 mm. The bone was assigned an elastic modulus of 6 GPa to be in the range of values measured by indentation in this study. 10 N of load was applied in the simulation and displacement was calculated. When the sample width was 3 mm, displacement was 9. 5 μm. When the sample width was 30 mm and 60 mm the displacement was 7. 7 μm. This implies that as the bone sample width is decreased below a critical level the elastic modulus measured by indentation will also decrease.
The cortical porosity calculated by the StrAx1. 0 software using the HR-pQCT scan images compared very well with the cortical porosity calculated by the micro-CT images (r 2 = 0. 87)  76. HR-pQCT scans can be performed on patients' wrists in vivo. The StrAx1. 0 software, thus, enables a doctor or researcher to reasonably calculate a patient's cortical bone porosity at the distal radius. The StrAx1. 0 software has also been applied to normal clinical CT scans (voxel size 740 μm) to measure cortical porosity. Cortical porosity measured with this technique was associated with patients fracturing their bones, independent of bone mineral density (BMD) and Fracture Risk Assessment (FRAX) score  56. Another potential solution for measuring porosity in vivo is magnetic resonance imaging (MRI) technology.
The received signal was digitised and stored using an acquisition card (Acqiris DP240, Acqiris, Switzerland) and post-processed in MATLAB (Mathworks, USA). The bulk wave velocity was calculated by dividing the sample length by the time of flight. The time of flight was recorded as the time from the ultrasound pulse being emitted to the signal's first deviation from zero, as explained in more detail in Peralta et al. 81. Six successive measurements with repositioning of the samples in between were done for all measurements and the average of the six velocity measurements was used to calculate the stiffness. Bulk wave velocity ultrasound measurements were performed in addition to RUS because bulk wave velocity measurements of bone stiffness have been more frequently reported in the bone literature.
Micro-Ct scanning for determining porosity. Samples were placed in custom-made, additivelymanufactured, cylindrical, polyamide-12 containers. The containers were 30 mm tall and had an inner diameter of 5 mm (designed to be just wide enough to fit the samples). Samples were placed at the bottom of the container and then immersed in phosphate buffered saline. This was to ensure the samples did not dry out during CT scanning. Samples were scanned individually in a high-resolution micro-CT scanner to a pixel size of 7 micrometres (μm), to determine cortical porosity (Zeiss Xradia 510 Versa, 50 kV, 4 W, 0. 4x objective, 8 second exposure, Bin 2, LE1 filter, 1601 projections over 360 degrees rotation, with a total scan time of 7 hours). Images (Fig. 8f ) were reconstructed using the scanner software, cropped using ImageJ (ImageJ, NIH, USA) and then exported as 8 bit data to Avizo (ThermoFisher Scientific, Oregon, USA) for visualisation and quantitative analysis.
01 mm at a displacement rate of 1. 8 mm/minute followed by 10 preconditioning cycles at an amplitude of 0. 01 mm and a frequency of 0. 5 Hz. These preconditioning cycles were carried out to ensure that there was good contact between the bone surfaces and the platens  44  , and to minimise end-effects  85. Low strain levels were used in the preconditioning cycles to minimise the risk of plastic deformation to the bone samples, as advised by Linde et al. 86  , Keaveny et al. 85  and Zhao et al. 50. Following preconditioning, samples were loaded to failure with a relative ramp to 2 mm displacement at a rate of 1. 8 mm/ minute. This corresponds to a strain rate of 0. 005/s, considered to be the quasi-static strain rate of bone from previous studies  44, 74, 87. The load-displacement data and sample dimensions were input into a custom MATLAB (Mathworks, USA) script that first converted the data into stress and strain and then plotted the stress-strain curve.
To calculate the elastic modulus, the script calculated the steepness of multiple, best-fit straight lines over 0. 2% strain ranges, plotted onto the loading curve, with varying origins. The maximum steepness line was used to calculate the apparent elastic modulus, ensuring the maximum modulus was calculated, similar to the method by Keaveny et al. 44. In addition, the maximum point on the stress-strain curve was recorded as the ultimate compressive strength. Ashing to determine bone mineral content. Samples were placed individually in ceramic crucibles and placed in a furnace (Fig. 8i ). 10 crucibles could be positioned into the furnace (Lenton EF 11/8B, Lenton, UK) at one time so samples were ashed in two batches using the method reported by Wang et al. 88. Bone samples were first dried at 70° Celsius overnight in the furnace.
The furnace was then heated to 800° Celsius and samples were heated at this temperature for 3 hours. The ashed samples were then weighed and this was recorded as the ash mass. The bone mineral density by ashing (BMDA) was calculated by dividing the ash mass by the sample volume. statistical analysis. The relationships between all the measurements were assessed by ordinary least squares regression and the Pearson's correlation coefficient, r, together with p values, were calculated using IBM SPSS v24 (IBM, USA). For data that were not normally distributed, the correlations between measurements were assessed by Spearman's Rank Correlation Coefficient, r s , with p values, using IBM SPSS v24 (IBM, USA). Graphs were plotted using the software Origin (OriginLab, USA). Correlation coefficients were reported as strong if greater than 0.
Acknowledgements The authors would like to thank  Dr Richard van Arkel  for analysing the compression testing data and producing the sample cutting clamp,  Shaaz Ghouse  for help with compression testing,  Ruben Doyle  for help with data presentation,  Dr Martin Jaere ,  Dee Fisher  and  Robyn Andrews  from  Embody Orthopaedic  for designing the sample container,  Professor Luc Vandeperre  for assistance with indentation testing,  Dr Michelle Oyen  for useful discussions and advice about indentation testing,  Dr Adrian Harris  from  Micro Materials  for assistance with indentation analysis,  Yuekang Du  for assistance with finite element analysis,  Mr Angus Lewis  for femoral head collection,  Dr Ruth Brooker  for help with the ashing process, patients for their bone samples and  Imperial Tissue Bank.
OSS/BSS-systems used by telecommunication companies to conduct their business are a combination of several subsystems that closely interact with each other. Since the activities of telecommunications companies are related to the processing of personal data of individuals and legal entities, such systems should be subjected to testing, which should continue until the end of the life cycle. The huge size of telecommunications companies' databases, as well as the number of tests required to cover the entire functionality of OSS/BSS-systems are an obstacle to conducting rapid testing. This article describes an approach to testing organization that solves this problem, based on the selection and keeping the test data up to date. The effectiveness of the proposed approach has been demonstrated experimentally.
Auto-test with a logical error can produce inadequate results. Automated testing requires much more resources to prepare for writing and executing tests. The tester is required to have knowledge of at least one of the popular high-level programming languages (for example, Java or Python), ability to work with UNIX-like operating systems, basic knowledge of networking, information security, version control systems, CI/CD principles, knowledge of databases, etc. At the same time, test automation team is only a small part of the whole automated testing process -it is necessary to create a specific testing environment and select people responsible for the subsystems as consultants. Despite such high demands, automated testing can significantly improve the quality of products and services produced by minimizing the human factor in the testing process while simultaneously accelerating it.
Problems of BSS/OSS-systems testing One of the typical problems of testing OSS/BSS systems is the large volume of databases. The higher the client base of a telecommunications company, the higher the amount of data to work with. It should be noted that not all records from the table could be useful for a particular test. Testers have to form relatively complex queries in the database, providing data filtering at the very start of testing process. This is necessary in order to reduce the complexity and remove redundant logic from the functions and methods that work with the results of these queries. The huge size of the database and the complexity of the queries lead to the fact that the auto-tests will spend a large amount of time on the selection of input data. One of many possible ways to solve this problem is to reduce the size of test databases.
This can occur at the deployment stage of the test environment. When replicating databases and devaluing the data contained in it, you can control the number of records that must be transferred as a result. However, there are two disadvantages to this method: 1. Reducing the volume of databases reduces reliability of the results of testing process; 2. The corruption of data that occurs when certain tests were started simultaneously. Obviously, full replication of production database is too expensive so companies will run certain procedures that will reduce the volume of test databases, but the amount of data must be enough to be used by multiple executions of auto-tests without the need of recreating test database very often. That means that the volume of databases can be still considered a problem.
Test data collection and distribution system To solve the problems that were described in the previous section, it is proposed to develop a special system for the preparation of test data, which is an intermediate layer between the test environment and the database containing necessary information. This system must consist of two main functions: 1. Selection of test data according to certain criteria and their storage in its own database; 2. The distribution of access to this data between tests. Selection of test data occurs after the first run of tests. All requests to receive information from the database are being sent through the system. At the initial tests execution the system receives and remembers the request, obtain data for this request from the test database, returns the desired value to the test, and then replenishes its own repository with a new set of test data in the background.
When you run the tests again, the system will immediately return information from its own repository, which will reduce the tests runtime. The distribution of data access between tests is organized by a special mechanism, which will be triggered whenever tests are requesting data. The mechanism sets a lock flag on the record, which will reset after some short time has elapsed. Based on the aforementioned information, let's formulate the main components that should be included in the test data storage system: 1. Database storing collected test data and info about selection criteria; 2. The mechanism for updating the test data; 3. The mechanism of blocking data that is currently processed by tests; 4. Interface of test interaction with the system. Let's also distinguish additional functionality: 1.
Test scenario and test environment A remote server rented from the cloud infrastructure provider DigitalOcean have been used as a test server. Characteristics of remote server are presented in Table  1. The process of connecting additional package of services to a subscriber was chosen as a test scenario. The scenario consists of six steps: 1. Test receives the identifier of the package as input data; 2. Test makes a request to the database to receive a suitable subscriber who does not have this package; 3. Test transmits obtained identifiers of the subscriber and the package to the system, which is responsible for connecting packages and services,; 4. The system modifies the data received by the subscriber and connects the package; 5. The system returns the result of the connection; 6. The test analyzes the result and displays the corresponding message.
The scheme of the test scenario is presented in Figure  1. In accordance with the test scenario, to implement the simulation environment, it is necessary to prepare a database and create a product connection server. PostgreSQL was chosen as the DBMS, since it is multiplatform and being distributed under the PostgreSQL License, similar to BSD and MIT licenses. The final database includes six tables: 5. RTPL_PACKS -a table connecting packages with rate plans. This table stores information about which packages will be connected to the subscriber on connection of a particular rate plan, as well as optional packages that can be connected in addition to the rate plan; 6. SUBS_PACKS -a table connecting packages with subscribers. This table stores information about which packages are already connected to the subscriber.
The ER-diagram of the developed database is presented in Figure  2. Creation of the database was automated by additional scripts including SQL-queries and modules written in Python. All clients' names are random sets of English characters. Date of birth is also chosen randomly, considering that the client cannot be younger than 10 years. The generation of the connection date also takes into account various impossible situations. For example it is impossible for a client to connect a rate plan years before the client was born. As for packages, when it comes to generating records in the "RTPL_PACKS" table, 10 random optional packages were selected for each tariff plan. The total numbers of records in the resulting database are shown in Table  2. Based on the description of the tables, the package is connected to the subscriber only when there is a corresponding entry in the "SUBS_PACKS" table.
This table is modified via using a products connection system. To develop a system for connecting products and services, Python 3. 7. 0 was used, as well as the «Flask» microframework, which was used to develop a small API for interacting with the system. The module «psycopg2» was used to interact with PostgreSQL. This module can be easily installed via the «pip» installer supplied with Python on any platform and does not require additional installation of PostgreSQL compatibility drivers. The choice of these tools is largely associated with ease of use and multiplatform nature. Product connection system consists of two functions that necessary for current test environment: 1. Processing the incoming POST-request for connecting packages to subscribers;; 2. Sending request to database in order to modify «SUBS_PACKS» using given information.
Implementing test data distribution system into testing environment Let's consider the execution of given test scenario using our test data distribution system. The scheme of the test scenario with new component is shown in Figure  3. Test data distribution system was embedded into modeled test environment. Auto-test responsible for recreating given test scenario was modified to send its requests into test data distribution system instead of sending them to database directly. The system itself was developed on the AIOHTTP framework for Python because this framework offers asynchronous processing of requests incoming from tests that reduces the time needed for processing and sustain effective interaction with test data. PostgreSQL is used as storage, but in the future, we will try to implement Redis instead for a faster interaction.
For described test scenario, the following functionality was implemented in test data distribution system: 1. Interaction interface between auto-test and this system; 2. Small and simple database for test data storage; 3. Database background filling mechanism; 4. Test data blocking mechanism. Algorithm of interaction between auto-test and the system: 1. Auto-test sends an HTTP-request to test data distribution system, that contains SQL-query to database; 2. The system checks the availability of data that fit to the given SQL-query in its own storage; 3. If the data was found then they are sent back to auto-test; 4. Otherwise, the system saves SQL-query in its own storage, run it directly on the main database and return result of this request to auto-test. Database background filling mechanism will use SQL-request remembered earlier to prepare new set of test data for future tests executions.
Cumulative light absorption and scattering throughout tissue layers increases optical aberrations and leads to drastic loss of spatial resolution and signal in deeper tissue. These issues defeat the goal of capturing nuclear features at the sub-micrometric scale throughout tissue layers, even when using objectives with high NA and lenses that correct for chromatic and axial aberrations. The advent of multiphoton imaging unlocked the potential for deep-tissue imaging (Figure  1 (e), see the orthogonal sections throughout the root and close up panel), particularly when combined with image restoration. Figure  1 (f) shows an example of 3D image restoration on the fly (using the commercial module Hyvolution, Leica microsystems, Germany) of root nuclei from the cortex layer. This approach resolves the intricate distribution of H1 variants in 3D within chromocenters and euchromatin (insets, upper right panel).
Image enhancement and rendering increases the possibilities to communicate relevant information from complex datasets. Image reconstruction and 3D rendering are useful for data presentation and interpretation. Image series can be represented with surface and volume features, on full or partial projections, using customized slice modes and rotations among the multiple possibilities offered by image processing software. Some rendering examples are illustrated in all figures and emphasized in Figure  4(a). Several open source and commercial software packages are available and user-friendly for the plant nucleus research community, as reviewed elsewhere  [44]. For image enhancement, images can be processed to increase the contrast between low and high signal intensities, reduce technical noise and enhance feature (edge) contrasts to emphasize distinct features relevant for interpretation (example Figure  4 (a3)).
Some examples of algorithms implemented in classical image processing software are based on the concepts of contrast-limited adaptive histogram equalization (CLAHE)  [114] , colour deconvolution  [115]  or image enhancement by edge detection. Fluorescence microscopy images typically benefit from denoising approaches  [116] , particularly when the image is corrupted by shot noise (i. e. discrete electronic noise produced by photon detectors and amplifier devices) often referred to as 'salt and pepper' background. Several algorithms are available as ImageJ plugins  [117]  or as denoising/smoothing filters in commercial image processing software. These image processing techniques should however not be applied prior to signal quantification as they will modify intensity distributions. Image segmentation of nuclear signals detected as distinct objects is used to characterise them in terms of their geometrical features (size, shape, smoothness) and their number and positions, either relative to each other or in the image coordinate system.
Historically, one of the first thresholding techniques, the Otsubased method, considers the image as being composed of two classes of pixels corresponding to the background and the object. The algorithm thus attempts to separate the pixels into two distributions classes with minimal intra-class variance and maximal inter-class variance  [126, 127]. This method works well if the object itself shows minimal contrast variation (i. e. homogenous labelling) and if individual objects are well separated from one another. The method is therefore not suitable for touching objects. At present there are about 15 standard approaches for threshold-based segmentation  [128] , but most neglect the spatial information present in the image. Another limitation appears in an automated batchprocessing mode. The variability in pixel (or voxel) intensity distribution and ranges across image datasets makes it difficult to apply the same threshold to all images; the user is then prompted to define a new threshold value for each image.
Semi-automated batch image processing In the past years, workflows based on open-source or commercial software have been developed and made available to the plant nucleus community to facilitate large scale measurements of nucleus shape and size, to quantify chromatin organization or to measure the position of a given fluorescent signal within the nuclear space. We describe here two alternatives, one developed for the open source platform ImageJ, and another for Imaris, a commercial solution for 3D visualization and image processing (Bitplane, CH). The first example is NucleusJ (Figure  4 )  [127, 131]  an ImageJ plugin coded in Java language. It includes all the necessary steps to process images of nuclei, to perform various analyses and to provide several quantitative parameters to describe the original image (Figure  4 (b1)).
We also found that alteration of nuclear morphology quantified by NucleusJ is associated with transcription of heterochromatic sequences that are usually silenced  [119]. The second example is the XTFISHInsideNucleus  [123] , a plugin developed in Python and implemented in the proprietary software Imaris. This plugin performs segmentation of the nucleus, nucleolus and punctate signals (such as FISH signals) in the nuclear space in a batch-compatible mode (Figure  4 (b2)). The segmentation procedure is based on thresholding and applies gaussian filters to smoothen the image. The user is prompted to adjust these parameters during the workflow, thus enabling an adaptive process. Distances are then computed between the punctate signals converted into spot objects and the nuclear periphery, the chromocenters and the nucleolus.