# Random Test Generation of Application Programming Interfaces

Eitan Farchi, Krithika Prakash, Vitali Sokhin

###### Abstract

Cloud high quality API (Application Programming Interface) testing is
essential for supporting the API economy. Autotest Assist is a random test
generator that addresses this need. It reads the API specification and deduces
a model used in the test generation. This paper describes Autotest Assist. It
also address the topic of API specification pitfalls which Autotest Assist may
reveal when reading the specification. A best practice is to add an
appropriate test to the regression once a problem is revealed and solved. How
to do that in the context of Autotest Assist’s random test generation is
covered.

##  1 Introduction

API economy is driving the digital transformation of business applications
across the hybrid cloud and edge environments. In such applications, micro-
services are typically defined and expose a set of API interfaces. Each micro
service serves a specific business need. By composing the micro services from
multiple vendors a greater business value is obtained. For example, a book
store may have an inventory micro-service the buyer can search and a shopping
cart micro-service that keeps an inventory of the books the buyer would like
to buy. In addition, a credit validation micro-service is leveraged from
another vendor and a book shipping micro-service by yet another vendor.
Together, the micro-services allow the buyer to search the bookstore, decide
on the books she would like to buy, and then buy them. The micro-services may
be placed in hybrid Cloud environments across edge locations and multiple
Cloud environments and are potentially accessed by the buyer from an edge
device. In such environments, in addition to the functional requirements,
communication failures, order of message passing between the micro services,
placement of the micro services and failure to react by a micro service
(sometimes referred to as circuit breaking) may result in quality issues.
Thus, in the API economy testing requirements should be addressed to create a
high quality solution.

An API call results in obtaining some resources that are then used to call
another API that belongs to the same or some other micro service thus
obtaining a business goal. In addition, an API interface constitute of several
input and output parameters. Thus, the possible sequences of API calls with
different parameters values create a huge space of possible user scenarios of
the APIs. As a result, it is not practical to attempt to exhaustively execute
all of the possible user scenarios. Traditional approaches to testing include
manually defining use cases that include calls to a sequence of APIs and
manually choosing parameters values using boundary conditions selection. This
process is sometimes called directed testing and is labor intensive. To ease
some of the effort involved in the testing of APIs we advocate the use of
random test generation instead of the manual design of test scenarios.

Under the random test generation paradigm we randomly choose an API to
execute, f(), and then randomly choose legal input parameters
$p_{1},\ldots,p_{k}$, for f(). Next, f() is run and the output and side
effects that occurred in the system are observed. This process is repeated
thus generating a random sequence of API calls. The following challenges need
to be tackled when following the random test generation paradigm.

  1. 1.

The input $p_{1},\ldots,p_{k}$ should be syntactically correct. Typically,
this requirement is easy to meet. A much stronger requirement that is harder
to meet is that the inputs $p_{1},\ldots,p_{k}$ should adhere to the
preconditions of the API f() if we intend that the call to f() succeeds. For
example, we may obtain a book from the inventory using one API, f(), and then
attempt to buy it using another API, g(). When calling the API g() we need to
hold a valid reference to a book, which is a pre-condition calls to g() need
to be meet.

  2. 2.

Be able to determine if the call to the API behaved as expected.

  3. 3.

If a problem occurred as a result of the random generation process, the system
needs to support its debugging.

  4. 4.

Given that we are also creating directed tests and have a test suite composed
of directed tests that we use to regress the system, how do we integrate a new
test obtained from the random test generation to the directed regression
suite? This question especially applies when the random test generation
revealed a problem and once the problem is debugged we would like to enhance
the regression with an appropriate test.

  5. 5.

How do we determine the coverage obtained by the random generation process?
Can we trust the random generation process to regress the system or should we
still develop a directed test suite?

To address challenge one and two above we read the API specification.
Implicitly that requires that the API specification defines its pre and post
conditions. Indeed one of the results of our approach which we elaborate on
below is a set of guidelines and best practices to the definition of the API
specification.

The third and forth challenges above are related. We keep a database (DB) of
the scenarios that the random test generation created. This DB is queried to
assist in the debugging and creation of an appropriate directed test that is
then added to the directed regression suite.

The last point has long term consequences on maturity of your random test
generation approach. If you can trust your coverage criterion, e.g., calling
all pairs of dependent APIs through the output of a resource by one API used
by the other API, you may regress the system by calling the random test
generation until that coverage criterion is met. We discuss that high level of
mature usage of random test generation below.

The rest of this paper is organized as follows. We first discuss API
specification and design and how it impacts effective API testing. Then we
introduce random test generation. Next we cover Autotest Assist, a specific
implementation of the random test generation paradigm. We conclude by
addressing the methodological challenges mentioned above in detail.

##  2 Functional random test generation

Another way for automatically generating test cases, which is not necessarily
dependant on any coverage model is using an OpenAPI-based random test
generation. This method has the ability to create sequences of random API
requests/responses, in a single or multiple processes concurrently.

Random test generation for functional testing of APIs has two main goals.
First, it automates the usually-manual process of writing tests, which is
labor-intensive, bug-prone on its own, and limited in its ability to cover the
API functionality. Second, it has the ability to generate API calls and
sequences which a human will not consider writing tests for, thus provide
higher and unique coverage, as well as hit hard-to-detect bugs.

###  2.1 Random test generation characteristics

Over the past few years, since REST APIs became the de-facto standard for
writing web applications, there have been several works on tools and
technologies for automatic test generation for APIs (see [Arc18], [Vag19],
[AGG+20]). The different tools can be characterized using several attributes.
We will use these attributes to discuss tradeoffs in this area, as well as
provide some examples and best practices.

####  2.1.1 Testing approach

The first aspect to consider is whether the tool uses the API source code
(”white-box”) or not (”black-box”). Needless to say, a white-box approach has
an enormous potential for leveraging the knowledge on the code structure and
the internal methods and parameters, for generating more qualitative tests.
However, it is not always possible to have access to the source code (e.g. due
to confidentiality). Furthermore, this technique is usually coupled with a
specific code language, and is therefore limited in its usage.

Most of the existing tools use the black-box approach, which is sub-optimal,
but more generic and easy to use. Using a white-box approach can be more
suitable for tools which aim at a specific code language, or at a concrete set
of APIs which need to be thoroughly tested (e.g. because they are part of a
mission-critical application).

####  2.1.2 Test-generation technique

There are many techniques for generating random test-cases: model-based,
fuzzing, property-based, and more. There is no ”right” technique, and each has
its own pros and cons. Model-based generation, for example, allows for a more
accurate test generation, which covers the API space better. However, it
relies on a relatively elaborate specification of the API, and depends on the
ability to discover connections between operations and resources in the API.
Fuzzing requires less structural data, but does rely on a ”good” set of
existing tests which can be used as a basis for the fuzzing algorithm.
Evidently, the choice of a test-generation technique is heavily influenced by
the experience and knowledge of the developers of the tool, rather than an
informative decision - as said, there isn’t a single ”best” method.

####  2.1.3 Test derivation

Some tools can derive concrete test-cases out of the randomly generated tests,
to be used in regressions. This is a powerful feature, that if exists, can
potentially make the manual test writing (almost) completely redundant. A
random test will usually contain symbolic variables, to pass from one
request/response to another, simply because the API is non-deterministic, and
can return different outputs in different invocations of the same request
(given the same initial state). Tools which don’t have this feature, are used
mainly for bug-hunting and system stressing, but can’t be used for building a
systematic regression suite.

####  2.1.4 State tracking

Some tools track an internal state for better generation and/or checking. This
internal state is supposed to (as much as possible) accurately reflect the
actual state of the system, with respect to the existing resources and
connections between them. The state can be used for better generation, for
example using existing resources for creating sub-resources or for deletion.
Furthermore, it can be used for better checking, for example when predicting a
response code of creation/deletion of an object, partially solving the
infamous oracle problem in SW testing

####  2.1.5 Checking method

One of the notoriously difficult problems in software testing (and testing in
general), is the oracle problem. API testing is not different, and several
methods for checking exist. First, all of the tools can perform syntactic
checking of responses, asserting that their format and content is valid with
respect to the API definition. However, many APIs are under-speficied, so this
type of checking is not that powerful. Another option is to detect all of the
$500$ responses as bugs. Usually this does the trick, unless the API allows
for these responses, making this check obsolete. The higher level of checking
is ”semantic checking”, in which the tool can predict whether the response
code which was returned is (one of) the correct code(s). This is much more
difficult to achieve, yet highly useful in detecting bugs.

####  2.1.6 Automation level

The different tools differ in the effort it takes to use the tool on a new
API. The ideal tool is one that needs no manual configuration - it takes the
API specification (and possibly other inputs, such as the source code), and
automatically starts generating tests which detect bugs. However, some manual
configuration is usually both needed and helpful, in order to direct the tool
towards more promising directions which will find more bugs.

##  3 IBM Autotest Assist Technology

In this section we describe Autotest Assist which is a model-based biased-
random test generator developed by IBM Research. In subsequent sections we
will explain the testing methodology that Autotest Assist implements. Autotest
Assist’s initial purpose was to help IBM in developing and testing its APIs
for various purposes such as IBM Public Cloud, middle-ware offerings, software
tools. Later, in collaboration with the IBM Product team, Autotest Assist
evolved to be an efficient testing tool that is now integreated into the API
Testing Component within the product APIConnect in Cloud Pak For Integration
(CP4I) 2022.2.1. For more details look at this blog.

Autotest Assist has shown a lot of value in testing certain types of APIs
during the development phase, before APIs are promoted to higher environments,
uncovering several unique bugs in the areas of syntactic errors, missing
implementation and also bugs that occur due to race conditions in the code.
Once Autotest Assist is set-up, it requires minimal human intervention. Any
subsequent effort is expended in triaging and debugging the failures reported
by Autotest Assist.

Typically a test generation tool generates unique test cases that are then
managed, scheduled and run manually by a testing framework. Autotest Assist is
not a typical test generation tool. Instead of generating unique tests that
then have to be run against the APIs, Autotest Assist executes or exercises a
sequence of tests, sending requests to the endpoint where the API is hosted.
It can be seen an ”exerciser” rather than as a test generation tool. Its
output is an unbounded stream of API requests, which are generated one after
another, in an online manner - each request depends on the internal state that
Autotest Assist maintains, which is a reflection of Autotest Assist’s
understanding of the union of the requests and responses it has generated so
far. Therefore, Autotest Assist does not generate (by default) unique,
isolated test-cases, but rather a sequence of requests which exercises the
System-Under-Test (SUT). The sequence of request generation will cease under
two scenarios: a) a timeout has occurred (test result is ”passed”), or b) an
error was detected (test result is ”failed”).

Autotest Assist is a black-box tool, that does not tie itself to particular
implementations or assumptions of APIs. That said, the tool can be adjusted to
improve its coverage and bug-finding capabilities, making it more of a ”grey-
box” for certain APIs. This is done for APIs which justify such effort, for
example, APIs that require a very high reliability. See section 4.5 on
customizations.

To setup Autotest Assist for usage on a given API, Autotest Assist first takes
the OpenAPI specification, and derives a specific model out of it. The model
generated contains the resources which appear in the API, as well as the
relations between them. We call this the ”semantic model”. Each resource is
modeled, and is used as a basic building block for test generation. In
addition, dependencies between resources are modeled: does resource A require
another resource B to be created (making A dependent on B). For example, we
may have 2 resources, Book and Author, such that creation of a Book requires
an Author to be provided as an input, making the Book resource dependent on
the Author. The semantic model is inferred using certain heuristics on the
OpenAPI specification structure. Expanding the semantics of OpenAPI is a hot
topic, and we believe that Autotest Assist’s generation of a semantic model
alone may have a significant value for many users, not just in the API testing
domain.

Autotest Assist has 2 modes of operation, sequential and concurrent. In the
sequential mode, each request is generated only after the response of the
previous generated request was received and checked. In this case, there is at
most a single request in flight at all times across the system. Such a mode of
execution maybe easier to debug, however this mode may hide underlying bugs
related to atomicity, as concurrency is not exercised. On the other hand, in
the concurrent mode, this restriction is removed, and several requests are
executed in parallel in the system. This is of course a more complicated mode
to generate requests and also to debug bugs. Its main advantage though is the
ability to find non-atomic issues eg. race condition bugs, which manifest as a
result of several requests accessing the same resource(s) in parallel.

Autotest Assist checking methods are:

  1. 1.

Syntactic checking of response body

  2. 2.

Check for HTTP Status Code 500 (i.e 5XX): ”Internal Server Error”

  3. 3.

Semantic checking of responses - making sure the response content accurately
matches the Autotest Assist’s internal state. When dealing with asynchronous
APIs, Autotest Assist needs to maintain partial internal states of API
requests and responses to perform semantic checking. This feature of the tool
is work-in-progress and is not available as part of CP4I release 2022.2.1

In general, we see two potential classes of users of Autotest Assist: One
class of users (typically Enterprise level customers) who dive deep into
testing a specific set of APIs, adding manual modeling and customization in
order to cover the entire depth of the API functionality using Autotest
Assist. The second class of users who benefit more on quantity over quality,
or breadth over depth when it comes to API testing: being able to test as many
APIs and operations as possible, with minimal manual effort from their testing
teams. Autotest Assist is developed with both types of users in mind. It
allows for naive users to use the auto generated semantic model with minimal
to no changes, at the same time for advanced users, the model can be
customized to suit more specific requirements.

Autotest Assist technology can be integrated into an existing testing
framework by extending the framework to configure and invoke Autotest Assist.
Typically in a test framework, a testing tool exists where Quality Assurance
engineers write test cases to test specific APIs, the framework validates
response with a known response and reports success/failures on each test case
which are in turn grouped to a test suite. These test suites can be scheduled
to run at specific times during various stages in the development and release
life-cycle. In such a framework, Autotest Assist tool can be integrated as a
”test suite” that can potentially augment or in a more mature model, replace
manual addition and updates of the test cases. Since Autotest Assist allows
for customization of the areas to be tested, QA engineers can schedule
Autotest Assist to generate requests on specific aspects of the API which may
not have been covered by the manual tests initially. Additional aspects of
”coverage” based testing is discussed in the conclusion section of this paper.

###  3.1 Types of bugs uncovered by Autotest Assist

In this section, we will describe a few bugs found by Autotest Assist in the
sample Bookshop application APIs as well as in the OpenShift APIs in the order
that they were found. This will give an idea of the types of issues that can
be uncovered by Autotest Assist. Although the examples are interesting they
are anecdotal and do not represent all types of bugs that can be found by
Autotest Assist.

####  3.1.1 API Schema mismatch errors

Autotest Assist first found API Schema mismatch errors. When Autotest Assist
was first run against the sample bookshop application, Autotest Assist ended
with a failed run. This was because a response received did not match the
schema in the specification. When Autotest Assist was first run on Openshift
APIs, it got _null_ for the _metadata.creationTimestamp_ property, even though
the schema did not allow it.

####  3.1.2 Backend implementation errors

Next, Autotest Assist exposed a few scenarios resulting in _500_ http error
response, which indicates an ”Internal Server Error”, in the sample Bookshop
application as follows: Autotest Assist created a _GET_ request for non-
existing customer and received _500_ http error response. Similarly, Autotest
Assist received _500_ http error response when trying to delete a customer
which was successfully created by a previous request. Additionally, Autotest
Assist discovered an issue with the DELETE operation on the path
”/api/v1/namespaces/invalid name/pods” of the Openshift APIs. The issue is
that the DELETE operation provided a good response even though Autotest Assist
generated an invalid value for a parameter.

##  4 Methodology

In the introduction section, we discussed the challenges of random test
generation. In this section, we will elaborate on these challenges, and how
they can be addressed using a testing framework, methodology and best
practices outlined below. The testing methodology implemented in Autotest
Assist is depicted in Figure 1.

Figure 1: Testing Methodology implemented in Autotest Assist

###  4.1 API Specification

An API can define an endpoint URL where several resources can be accessed
using a main API URL (root path) and multiple sub-paths. An Inter-API system
is one in which each microservice defines a set of APIs for specific functions
and a collection of microservices and their APIs together provide a complete
application environment. On the other hand, an Intra-API system is based on a
set of operations and parameters that are used within the API itself. Systems
can be either inter-API or intra-API or both. A single API endpoint can expose
$n$ different operations on $m$ different resources. Typically, related
functionalities and resources are grouped under one API which defines its
boundaries and scope.

The correctness of the API requests require proper design and communication on
both inter-API and intra-API systems. For example, the BookStore Application
can expose the following APIs: Registration API, Locations API, Catalog API,
OrderProcessing API and Payment API. Each of these APIs have interdependency
between them, for example you cannot invoke the Payment API without an OrderId
or you cannot access the OrderProcessing API before going through the
Registration API and so on. In addition, each of these APIs in turn can have
multiple resources and objects defined. For example, the Registration API can
have two resources Customer and Book. Operations on these resources could be
”CreateNewCustomer” ”GetCustomerID”, ”GetBookID”, ”PostBookToCustomer”,
”DeleteBook” and so on. One cannot invoke the operation GetCustomerID without
invoking CreateNewCustomer first. The order of invocation of the operations
impact the underlying memory allocation strategies for the resources. These
form the intra-API resources dependencies. As in the case of inter-API
communication, the same set of challenges also exist for intra-API
communication. Again we need to ensure that dependencies on resources and
operations are derived and understood well before a specific API can be
exercised. The key to getting the resources and operations defined correctly
in the API specification heavily relies on the design and documentation of the
APIs.

Designing an API is more of an art. There is no one right or wrong way to do
it. However, there are some basic rules and best practices that would help
guide towards designing APIs that are readable, testable and extensible. IBM
Cloud API Handbook is a good resource. The API specification should ensure to
reflect the correct resource allocation model of the underlying resources. For
example, the specification should define an API path to perform a ”CREATE”
operation on a new resource which allocates a unique ID to the resource. This
ID should then be referenced in the API path to perform the ”DELETE”
operation.

Correct resource allocation, usage and release is an important part of API’s
quality. To enable the testing of problems related to resource allocation and
usage, the API specification needs to define them. There are ML technologies
that tries to infer the dependencies between resources and their operations,
but starting with a good API design with explicit definitions sets the
foundation for a strong and effective API testing.

###  4.2 Semantic Model

A semantic model is derived based on the OpenAPI specification. A well
designed API yields a closer to accurate model derived in an automated manner
- we call this automation framework an OpenAPI Analyser. Autotest Assist has
implemented such an analyser. The analyser can extract the resource
dependencies from the APIs using the names and descriptions of the parameters
specified. It can use Natural language processing (NLP) functions to determine
if two or more operations are dependent on each other based on the parameters
names they are referring to. In such a case the output from one operation is
fed as input to the other. The analyser builds a file that can be reviewed and
updated by the API Developer who is expected to have a better understanding of
the dependencies of resources used by the API. The semantic model output also
indicates to the API Developer how well the API has been designed. If the API
design is not well done, this gives an opportunity to the developer to revise
the APIs specification in accordance with the best practices.

###  4.3 Requests Generator and Checker

The Generator and Checker form the core components of the Autotest Assist
framework. The semantic model provides a resource-centric view of an API,
which indicates all the operations defined in an API attributed to a specific
resource they operate on. For example, a bookshop API contains a resource
called _Book_ and there are operations which allow to create a book, delete a
book, modify or retrieve a list of existing books. With this semantic model as
the input, the Generator component first randomly selects a resource from a
list of resources defined in the model, then it randomly selects an operation
from a list of resource operations. Once an operation is selected, the
Generator has to generate values for operation parameters. Before Autotest
Assist starts request generation, it analyzes an OpenAPI specification and
creates a sampling specification for each operation. The sampling
specification defines domain and value distribution for each operation
parameter. When the Generator needs to specify values for operation
parameters, it requests a single sample from the sample specification.

Once a response is received, Autotest Assist checks if its status code is
defined in the specification. If the status code is not defined, the Checker
reports an error. For example, all _5XX_ status codes are reported as errors
by this checker. If the status code is defined in the specification, Autotest
Assist validates the response against a schema defined in the specification
for this status code and response content type. The above checks belong to
syntax checking and performed directly against the specification.
Additionally, Autotest Assist can perform semantic checking, where it tracks
resource state and predicts what status code has to be reported. For example,
if the bookshop application returns positive status code for a book which was
removed, the semantic checker could report an error.

###  4.4 Internal States

Autotest Assist stores information regarding resources it creates or discovers
in internal states. The information is updated not only by operations which
report resource description, such as _GET_ or _POST_ , but also by operations
which modify or delete a resource.

The state information allows to get good responses for requests which has to
provide resource ids in their input. For example, an operation which creates
an Order in the bookshop application has to specify an id of a customer and
ids of books which were ordered. To create such a request, the Generator
requests ids of all customers in the internal state and randomly selects one
of them. Additionally, the Generator also requests ids of the Book resources
and randomly selects one or more ids to create a request.

The internal state also allows Autotest Assist to perform semantic validation
as described in 4.3.

###  4.5 Customizations

Any random test generator framework is successful only when it exposes and
allows the customization of inputs and configurations of the internal
framework components. In this random testing methodology and framework,
although the system randomly generates tests, it allows for the user of the
framework (API Developer or tester) to specify which areas of the APIs the
framework should put more focus on. For example, the API tester can customize
the tool to add more weight to the PUT operation over the GET operation in
which case PUT requests are generated proportionally more than the GET
requests. Other areas of customziations can include error handling, duration
of the tests (can range from 2 minutes to 20 hours), stop/exit criteria and so
on.

###  4.6 Debugging the System Under Test (SUT)

Regression testing is the process of running a set of existing functional and
non functional tests in order to determine if a change to the System Under
Test (SUT) due to a bug fix or software enhancement caused a problem. A
regression test is automated if the results of each tests, i.e., whether it
succeeded or failed, are determined programmatically. In such a case, once the
regression is run, a report is automatically produced that states if each of
the tests that constitute the regression passed or failed. An automatic
regression on a SUT increases the confidence of the development team in their
ability to fix and progress the SUT while keeping its design clean. This in
turn increases the life span of the software and avoids accumulating technical
debt.

It is a best practice to enhance an automatic regression with tests that test
for bugs that were found and corrected in the software. This needs to be done
with care to avoid accumulating essentially duplicate tests and ending up with
a regression that takes too long to run.

When random test is used it may be desirable to follow the same practice of
adding individual tests generated by the random test generation framework into
the regression test bucket. This process is however non trivial. The random
generation process may have run for a long time until the problem emerged.
Thus, simply re-running the random test generation sequence of API calls as
part of the regression is not viable. In addition, the random test generator
does not produce a re-runnable set of operations. The good news is that in
order to debug a sequence of API calls produced by the random test generation,
the developer can create a smaller, minimal, execution that could produce the
same problem. This debugging step is sometimes referred to as ”recreate” and
is many times necessary in order to debug the problem. In order to enable the
recreate process, the random test generation saves the sequence of API calls
that lead to the failure. The recreated test is the test that could be added
to the regression.

At a higher maturity level one could trust the random generation process
completely and drop the need for a regression test. This includes the
development of some statistics of how long the random test generation needs to
run in order to reveal a bug of the sort that was revealed by the random
generation before the fix. Intuitively, the random test generation needs to
run long enough so that it is unlikely that the recreated test will not occur.
For example, if the random test generation is calling 10 APIs, and the bug is
revealed by calling one of them, then we need to randomly generate tests so
that it is unlikely that an API will not be invoked. In other words, we will
need to run the random test generation, and pick up an API to execute at
random, on the order of a 100 or more times.

##  5 Conclusion

In this paper we discussed Random Test Generation which introduces a different
perspective and approach on testing API endpoints than the traditional test
automation frameworks. The random test generator methodology uses the Open API
specification to derive a semantic model of the resources used within an API,
generates test requests, maintains internal state of requests and responses
received, uses the internal state and a sampling space to generate newer
requests continuously and intelligently deduce syntactic and semantic errors
of the APIs as well as the backend systems.

The random test generation fits perfectly in an API development phase, though
nothing prevents it from using it in a production phase as well. The framework
can be extended to track the coverage of the APIs exercised. By providing a
view of the number of the APIs requests, operation and parameter values, the
framework can give a powerful insight into the areas that lack coverage. By
classifying the areas of desired coverage based on a domain, for example,
security or OWASP top 10 security venerability, performance related test
cases, race conditions related test cases, the model can become highly
extensible and can be focused on specific areas. We expect this methodology to
fit well within an existing testing dashboard alongside any existing test
automation framework. In an established and mature implementation, it has the
potential to replace the traditional management of test cases entirely.

## References

  * [AGG+20] Vaggelis Atlidakis, Roxana Geambasu, Patrice Godefroid, Marina Polishchuk, and Ray Baishakhi.  Pythia: grammar-based fuzzing of rest apis with coverageguided feedback and learning-based mutations.  arXiv preprint arXiv:2005.11498, 2020.
  * [Arc18] Andrea Arcuri.  Evomaster: Evolutionary multi-context automated system test generation.  page 394–397. In 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST), 2018.
  * [Vag19] Marina Polishchuk Vaggelis Atlidakis, Patrice Godefroid.  Restler: Stateful rest api fuzzing.  page 748–758. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), 2019.


# Evidence of gradients of density and magnetic field in the remnant of
Tycho’s supernova

Oleh Petruk INAF-Osservatorio Astronomico di Palermo, Piazza del Parlamento 1,
90134, Palermo, Italy  Institute for Applied Problems in Mechanics and
Mathematics, Naukova Street 3-b, 79060 Lviv, Ukraine  Taras Kuzyo Institute
for Applied Problems in Mechanics and Mathematics, Naukova Street 3-b, 79060
Lviv, Ukraine  Mariana Patrii Faculty of Physics, Ivan Franko National
University of Lviv, Kyryla and Methodia 8, 79005 Lviv, Ukraine  Laura Chomiuk
Center for Data Intensive and Time Domain Astronomy, Department of Physics and
Astronomy, Michigan State University, East Lansing, MI 48824, USA  Maria Arias
Leiden Observatory, Leiden University, PO Box 9513, 2300 RA, Leiden, The
Netherlands  Marco Miceli Dipartimento di Fisica e Chimica E. Segrè,
Università degli Studi di Palermo, Piazza del Parlamento 1, 90134, Palermo,
Italy  INAF-Osservatorio Astronomico di Palermo, Piazza del Parlamento 1,
90134, Palermo, Italy  Salvatore Orlando INAF-Osservatorio Astronomico di
Palermo, Piazza del Parlamento 1, 90134, Palermo, Italy  Fabrizio Bocchino
INAF-Osservatorio Astronomico di Palermo, Piazza del Parlamento 1, 90134,
Palermo, Italy

###### Abstract

By using surface brightness maps of Tycho’s supernova remnant (SNR) in radio
and X-rays, along with the properties of thermal and synchrotron emission, we
have derived the post-shock density and magnetic field strength distributions
over the projection of this remnant. Our analysis reveals a density gradient
oriented towards the north-west, while the magnetic field strength gradient
aligns with the Galactic plane, pointing eastward. Additionally, utilizing
this magnetic field map, we have derived the spatial distributions of the cut-
off frequency and maximum energy of electrons in Tycho’s SNR. We further
comment on the implications of these findings for interpreting the gamma-ray
emission from Tycho’s SNR.

ISM: supernova remnants: individual (Tycho SNR) – ISM: structure – ISM:
magnetic fields

##  1 Introduction

The remnant of Tycho’s supernova (SN1572, G120.1+1.4) is observed at all
wavelengths of the electromagnetic spectrum and marks the site of a type Ia
supernova that appeared in 1572 (Krause et al., 2008). Cosmic rays are
accelerated in Tycho’s supernova remnant (SNR) to high energies (Morlino &
Caprioli, 2012). The availability of a significant amount of observational
data over the past decades makes this object one of the most interesting
research targets.

Multiple radio and X-ray observations indicate that the expansion of the
remnant into the interstellar medium (ISM) is anisotropic (Reynoso et al.,
1997; Katsuda et al., 2010; Williams et al., 2016; Tanaka et al., 2021). The
expansion parameter $(\Delta R/\Delta t)/(R/t)$ for the forward shock radius
$R$ in Tycho’s SNR varies between 0.2 and 0.8 as measured in radio or X-rays
(Reynoso et al., 1997; Katsuda et al., 2010). Thus, there should be
irregularities in the ISM density that cause such variations in the proper
motion of the shock.

There have been multiple attempts to identify an interaction between the
remnant and dense clouds in its vicinity by considering stronger shock
deceleration (Reynoso et al., 1999; Lee et al., 2004; Zhou et al., 2016; Chen
et al., 2017), or by measuring density variations around the shock front,
which could be interpreted as the presence of local ISM gradients (Vigh et
al., 2011; Williams et al., 2013). There are a number of studies that have
addressed the distribution of dense molecular material around the location of
Tycho’s SNR (Reynoso et al., 1999; Xu et al., 2011; Lee et al., 2004; Cai et
al., 2009; Ishihara et al., 2010; Chen et al., 2017).

Spatially resolved X-ray spectroscopy enables detailed ejecta velocity
measurements from Doppler shifts in the source’s emission lines (Hayato et
al., 2010; Sato & Hughes, 2017; Millard et al., 2022; Godinaud et al., 2023;
Uchida et al., 2024). It also reveals asymmetries in expansion of Tycho’s SNR,
and allows us to constrain the ejecta structure.

Little is known about the interstellar magnetic field (ISMF) structure in the
remnant’s surroundings. Several authors impose limits on the magnetic field
(MF) strength in the remnant based on observational data (e.g. Cassam-Chenaï
et al., 2007; Wilhelm et al., 2020; Reynolds et al., 2021). Radio and X-ray
polarization studies (Reynoso et al., 1997; Ferrazzoli et al., 2023) indicate
a predominantly radial MF orientation with an amplification/compression factor
of about 3.4 at the shock front.

Three-dimensional magneto-hydrodynamic (3D MHD) simulations of SNR evolution
are necessary for a better understanding of the SNR structure, the physical
processes related to the supernova explosion and its expansion into a non-
uniform ISM, and for testing hypotheses about the cosmic ray acceleration and
its high-energy emission. There are several HD or MHD models of Tycho’s SNR
that aim to explain its observational features as well as azimuthal
asymmetries (Chiotellis et al., 2013; Williams et al., 2017; Fang et al.,
2018; Ferrand et al., 2019; Moranchel-Basurto et al., 2020; Kobashi et al.,
2024). The structure of the ISM density and the MF are crucial inputs for MHD
models. Indeed, the ISM density is one of the key factors affecting the SNR
shock wave dynamics. On the other hand, the MF is crucial for the non-thermal
emission from SNRs, and for the cosmic ray acceleration. It could be
important, too, during the interaction of the remnant with circumstellar
medium or ISM inhomogeneities. It can also damp HD instabilities that can
fragment the inhomogeneities after the shock passage. Furthermore, the MF is
responsible for the (partial) suppression of thermal conduction (Orlando et
al., 2008).

The goal of this paper is to provide observation-based evidence for the large-
scale gradients in both ISM density and ISMF strength that have direct
implications for the evolution of Tycho’s SNR. As a next step, we produce
images of the distribution of the cut-off frequency and the maximum energy of
electrons over the SNR.

##  2 Observations and data reduction

We have used the 1.4 GHz map produced by Williams et al. (2016) from Karl G.
Jansky Very Large Array (VLA) observations of Tycho’s SNR. The data were taken
in 2013–2014 from a combination of A, B, C, and D configurations, observed
under project code VLA/13A-426 (PI J. W. Hewitt). Data from two spectral
windows covering 1314–1442 GHz were used to image the SNR using uniform
weighting. The resulting L-band map has a resolution of 1.91′′, and a pixel
size of 0.4′′.

The X-ray maps in the photon energy ranges $1.2-4.0$ keV, $4.1-6.0$ keV and
$3.0-6.0$ keV are derived from Chandra data taken in 2015 (obsid 15998). They
were analyzed with the Chandra Interactive Analysis of Observations (CIAO)
v.4.12 software. The data were reprocessed with `chandra_repro` and X-ray maps
were produced with the `fluximage` script. The derived X-ray maps have a
resolution and pixel size of 0.492′′. The radio and X-ray images are taken at
almost the same epoch, and therefore no correction is needed to account for
the SNR expansion between the observations. The FITS files of the X-ray images
are reprojected to the same pixel grid as the radio map to allow for a pixel-
to-pixel analysis. This is done by using the flux-conserving function
`reproject_exact` from the `astropy` library.

For the spatial variation of the radio spectral index $\alpha$, we have used
the $40^{\prime\prime}$ map derived by Arias et al. (2019). It was made by
combining LOw Frequency ARay (LOFAR; van Haarlem et al., 2013) data at 48.3
MHz, 67.0 MHz, and 144.6 MHz with VLA data at 327 MHz (Katz-Stone et al.,
2000) and 1382 MHz (Williams et al., 2016). The spectral index map was
produced by, for each pixel, fitting for a value of the flux density, spectral
index, and line-of-sight absorption. The spectra index $\alpha$ (where flux
density $S_{\nu}\propto\nu^{-\alpha}$) varies in value from $0.55$ to $0.75$
over the surface of Tycho’s SNR. The pixel size in the the spectral index map
is larger than in the radio and X-ray maps. Therefore, we prescribed the same
radio spectral index for all pixels in our grid which correspond to a single
one in the spectral index image.

##  3 Results

###  3.1 Density and magnetic field strength

Our goal is to understand the large-scale distribution of the density and MF
strength around Tycho’s SNR. We have adopted our method for processing maps of
SNRs in different photon energy ranges (Petruk et al., 2009). The basic idea
is to derive images of the global distribution of density and MF strength over
Tycho’s SNR resulting from the evolution of the plasma inside (including both
components: the swept-up ISM and the ejecta) after impact with the ambient
medium.

Figure 1:  Left: Density distribution derived from the thermal X-ray image of
Tycho’s SNR and equation (5). Right: Distribution of MF strength derived from
the radio and thermal X-ray images of Tycho’s SNR and equation (6). The color
scales are in arbitrary units. The outer contour of the SNR (white line) is
produced from the radio image. The white cross corresponds to the geometrical
centre of the SNR, while the black one corresponds to the actual location of
the explosion. The yellow line passes through the two centres. The white
dashed lines mark Galactic coordinates $l=120.1\arcdeg$, $b=+1.4\arcdeg$. The
Galactic plane is located below the remnant. The grid of equatorial
coordinates is parallel to the edges of each figure; north is on top, east on
the left. Both images (with size $1500\times 1500$ pixels) are smoothed with a
Gaussian ($\sigma\approx$ 20 pixels) to reduce small-scale fluctuations.

The synchrotron radio emissivity is:

$\epsilon_{\mathrm{r}}\propto KB^{(s+1)/2},$ (1)

where $K\propto n$ is the normalization of the electron spectrum,
$s=2\alpha+1$, $\alpha$ is the radio index, $n$ is the number density, and $B$
is the MF strength of the component in the plane of the sky. The surface
brightness in each pixel of an image is the sum of the emissivity along the
line of sight inside the SNR.

We can write the radio brightness in each pixel as:

$q_{\mathrm{r}}\propto\eta_{\mathrm{r}}nB^{(s+1)/2},$ (2)

where $\eta_{\mathrm{r}}$ is a geometrical factor, different for the different
pixels in the image. It accounts for the distribution of the radio emission
along the line of sight inside the SNR.

The thermal X-ray emissivity is:

$\epsilon_{\mathrm{x}}\propto n^{2}\Lambda(T,\tau),$ (3)

where $\Lambda(T,\tau)$ is a cooling function for optically thin plasma with
temperature $T$ and ionization state as characterized by the parameter $\tau$.
Tycho’s SNR is a young object with a high shock speed $V$ (average $V\approx
3300{\,\rm km/s}$ for distance $d=2.3{\,\rm kpc}$), and high post-shock
electron temperatures $T>10^{7}{\,\rm K}$ (Williams et al., 2013). For the
thermal X-ray map, we use the X-ray data in the photon energy range
$1.2-4{\,\rm keV}$, where the function $\Lambda(T)$ is approximately constant
for such temperatures and different ionization states (Appendix A). If this is
the case, then the surface brightness in each pixel of the image is
approximately:

$q_{\mathrm{x}}\propto\eta_{\mathrm{x}}n^{2},$ (4)

where $\eta_{\mathrm{x}}$ is a geometrical factor for the thermal X-ray
emission.

Expression (4) yields the density distribution over the SNR projection:

$n\propto(q_{\mathrm{x}}/\eta_{\mathrm{x}})^{1/2}.$ (5)

The expression for the MF map over the SNR follows from equations (2) and (4):

$B\propto\left(\frac{q_{\mathrm{r}}^{2}}{q_{\mathrm{x}}}\frac{\eta_{\mathrm{x}}}{\eta_{\mathrm{r}}^{2}}\right)^{1/(s+1)}.$
(6)

By using $n$ from equation (2) in equation (4) we assume the same injection
efficiency for electrons in the forward and reverse shocks. Differences in
density between the shocked ISM and the ejecta material are reflected in the
geometrical factors, which account for the internal structure of the remnant.

The geometrical factors $\eta_{\mathrm{r}}$, $\eta_{\mathrm{x}}$ vary from
pixel to pixel. They may be estimated from geometrical considerations and the
internal profiles of emissivity for the SNR. Namely, we use the Abel
inversion:

$\eta\left(\overline{r}\right)=2\int_{\overline{r}}^{1}\overline{f}(r^{\prime})\frac{r^{\prime}dr^{\prime}}{\sqrt{r^{\prime
2}-\overline{r}^{2}}}$ (7)

where $\overline{r}=r/R$, $r$ is the distance from the explosion point, $R$ is
the SNR radius, $\overline{f}(r)=f(r)/f_{\mathrm{s}}$, $f_{\mathrm{s}}\equiv
f(R)$ is the post-shock value of the function $f(r)$, which represents the
spatially variable part of the emissivity. We adopt the functions
$f_{\mathrm{r}}=nB^{3/2}$ for the radio band and $f_{\mathrm{x}}=n^{2}$ for
the thermal X-rays. They are calculated using $n(r)$ and $B(r)$ from numerical
simulations, namely, with the radial density and MF profiles for the remnant
of an SN Ia explosion at age 450 yrs from our one-dimensional MHD simulations
(Petruk et al., 2021). It appears that
$\eta_{\mathrm{r}}\approx\eta_{\mathrm{x}}$ for $\overline{r}=0.75-1$
(numerically, they are in the range $0.20-0.36$), and differ from one another
by about $30\%$ for smaller radii $\overline{r}<0.75$ (with values between
$0.12$ and $0.20$). We apply these radial functions
$\eta_{\mathrm{r}}(\overline{r})$ and $\eta_{\mathrm{x}}(\overline{r})$ for
different azimuths by scaling them with their respective $R$ for each
direction from the explosion center. We take the coordinates of the SN center
from Xue & Schaefer (2015). Note that $\eta$ is determined by using a
normalization to the post-shock values ($\bar{r}=r/R$,
$\bar{f}=f/f_{\mathrm{s}}$). Therefore, equations (5) and (6) for the density
and MF strength give not the average values along the line of sight, but
rather the post-shock values of $n$ and $B$.

The derived images for the post-shock number density and the post-shock MF
strength in Tycho’s SNR are shown in Fig. 1. There are also two centres shown
on these plots: the geometrical center (which corresponds to the circular fit
of the outer edge of the SNR; Warren et al., 2005; Katsuda et al., 2010), and
the actual center (estimated from the backward extrapolation of the proper
motion vectors for different filaments; Xue & Schaefer, 2015).

Figure 2:  Top: MF strength $B$. The distribution of values of $B$ is close to
a Gaussian with $120\pm 23{\,\rm\mu G}$. Centre: Cut-off photon energy
$h\nu_{\mathrm{cr}}$ derived from observational data with Eq. (9). Bottom:
Maximum energy of electrons $E_{\mathrm{max}}$ as given by Eq. (10).

###  3.2 Cut-off frequency and maximum energy of the electrons

Once we have the map of the MF, we may apply a procedure similar to one used
in the `srcut` spectral fitting model in `XSPEC` and consider the particle
acceleration. We use the fluxes at the radio $\nu_{\mathrm{r}}$ and the X-ray
$\nu_{\mathrm{x}}$ frequencies as well as the radio spectral index to
reconstruct the broadband synchrotron emission of the radiating electrons.

Tycho’s SNR is a young object. The maximum energy of the electrons
$E_{\mathrm{max}}$ is likely limited by its age rather than radiative losses.
A good proxy for the particle distribution in energy, in this case, is a power
law with an exponential cut-off. The accurate approximation to the synchrotron
spectrum corresponding to such a model is given by equation (8) in Petruk et
al. (2009):

$\epsilon_{\mathrm{xs}}=\epsilon_{\mathrm{r}}\left(\frac{\nu_{\mathrm{x}}}{\nu_{\mathrm{r}}}\right)^{-(s-1)/2}\exp\left[-\beta_{\mathrm{x}}\left(\frac{\nu_{\mathrm{x}}}{\nu_{\mathrm{cr}}}\right)^{0.364}\right],$
(8)

where $\nu_{\mathrm{cr}}=c_{1}BE_{\mathrm{max}}^{2}$ is the cut-off frequency
(i.e. the critical frequency for the electrons with the maximum energy),
$\beta_{\mathrm{x}}=1.46+0.15\cdot(2-s)$, $c_{1}=6.26\times 10^{18}{\,\rm
cgs}$, and $\epsilon_{\mathrm{xs}}$ refers to the X-ray synchrotron emission.

We have to account for the geometrical factors when applying this relation to
the maps: $q_{\mathrm{r}}=\eta_{\mathrm{r}}\epsilon_{\mathrm{r}}$,
$q_{\mathrm{xs}}=\eta_{\mathrm{xs}}\epsilon_{\mathrm{xs}}$. It is known that
the length scale for the radial distribution of the X-ray emitting electrons
is shorter than for the radio emitting particles. The synchrotron X-ray
emission is from electrons with energies around $E_{\mathrm{max}}$. Therefore,
their normalized density $\bar{n}=n/n_{\mathrm{s}}$ downstream of the shock is
about $e$ times smaller compared to the normalized density of electrons with a
power-law spectrum. Thus, the geometrical factor for the synchrotron X-rays is
$\eta_{\mathrm{xs}}\simeq e^{-1}\eta_{\mathrm{r}}$. By solving equation (8)
for the cut-off frequency, we have:

$\nu_{\mathrm{cr}}\simeq\nu_{\mathrm{x}}\left(\frac{1}{\beta_{\mathrm{x}}}\ln\left[\frac{\eta_{\mathrm{xs}}q_{\mathrm{r}}}{\eta_{\mathrm{r}}q_{\mathrm{xs}}}\left(\frac{\nu_{\mathrm{r}}}{\nu_{\mathrm{x}}}\right)^{(s-1)/2}\right]\right)^{-2.75}.$
(9)

We use $\nu_{\mathrm{r}}=1.4\times 10^{9}{\,\rm Hz}$,
$\nu_{\mathrm{x}}=1\times 10^{18}{\,\rm Hz}$ (corresponding to $4.1{\,\rm
keV}$) and, for $q_{\mathrm{xs}}$, the hard X-ray image of Tycho’s SNR in the
$4.1-6$ keV range.

The definition of the critical frequency gives the expression to produce the
map of the maximum energy of electrons from the maps of $B$ and
$\nu_{\mathrm{cr}}$:

$E_{\mathrm{max}}=\left(\frac{\nu_{\mathrm{cr}}}{c_{1}B}\right)^{1/2}.$ (10)

The image of MF $\bar{B}$ on Fig. 1 is in normalized units. In order to
convert it to physical units $B$, we calculate the mean value of the MF
strength in normalized units $\langle\bar{B}\rangle$ and assume that this
value corresponds to the mean field in the remnant $\langle
B\rangle=120{\,\rm\mu G}$. Fig. 2, top, shows the map of the MF where each
pixel has strength $B=\bar{B}\cdot\langle B\rangle/\langle\bar{B}\rangle$. We
see from this figure that the mean value which we adopted provides $B\simeq
200{\,\rm\mu G}$ in the regions along the SNR rim; this value coincides with
that estimated by other authors (Reynolds et al., 2021, and references
therein). Thus, we substitute equation (10) with $B$ calculated in this way.

The images in Fig. 2 show the distribution of the cut-off frequency and the
maximum energy of the electrons over Tycho’s SNR obtained with this approach.

Although synchrotron emission dominates in the regions around the edge of the
SNR (Lopez et al., 2015), thermal emission also contributes to the total flux
in the hard X-rays. In order to be certain in our results, we calculate
$\nu_{\mathrm{cr}}$ by also considering the synchrotron-to-thermal X-ray
fraction $\kappa$. By utilizing Chandra and IXPE observations, Ferrazzoli et
al. (2023) derived the synchrotron fraction map for the 3–6 keV photons over
Tycho’s SNR. In this photon energy range, the value of $\kappa$ varies from
0.16 to 0.90 across the SNR (their figure 7). We have used this map by setting
$q_{\mathrm{xs}}=\kappa q_{\mathrm{xh}}$ where $q_{\mathrm{xh}}$ corresponds
to the observed X-ray map in $3-6$ keV. The images of $\nu_{\mathrm{cr}}$ and
$E_{\mathrm{max}}$ derived in this way are the same as on Fig. 2 with a bit
lower resolution due to the structure of the map for $\kappa$.

Figure 3: Density profiles corresponding to the remnants of an explosion in an
ISM with density distribution (11) with $h=R$ and $h=2R$, compared to the case
of a uniform ISM density $n_{\mathrm{o}}=\mathrm{const}$. $R$ is the SNR
radius in the constant $n_{\mathrm{o}}$. The profiles correspond to an age of
450 yrs and are the result of 1-D numerical simulations for an initial ejecta
structure corresponding to SNIa (see details in Petruk et al., 2021).

##  4 Discussion and Conclusions

###  4.1 Gradients of density and magnetic field strength

We have already noted at the end of Sect. 3.1 that our density and MF maps
were derived in such a way to give the post-shock values of $n$ and $B$.
Although the ejecta material considerably contributes to the thermal X-ray
emission in Tycho’s SNR, the left map on Fig. 1 shows the large-scale
distribution of the ambient density. The density of the shocked ejecta
reflects the large-scale structure of the ISM because the flow structure
adapts to the ambient conditions. Really, Fig. 3 shows the profiles of the
density behind a shock evolving in an ISM with density

$n_{\mathrm{o}}(r)=n_{\mathrm{o}}(0)\exp(r/h),$ (11)

where $r$ is the distance from the explosion center and $h$ the scaling factor
for the non-uniformity. Indeed, the ejecta density (between 0.7 and 0.8 $r/R$)
is higher in the case of a stronger gradient. Another piece of information
from this plot is that the different profiles are quite similar and may be
scaled. This provides a justification for our procedure to use the geometrical
factors $\eta$.

We have previously studied how the non-uniformity of interstellar density and
interstellar MF affects the thermal X-ray (Hnatyk & Petruk, 1999), and
nonthermal radio (Orlando et al., 2007), X-ray and gamma-ray (Orlando et al.,
2011) morphologies of SNRs. Comparing Fig. 1 with the general properties
revealed in these references, we may come to the following conclusions about
gradients.

It is apparent from Fig. 1, left, that the density is higher in the north-west
region. The yellow line is plotted to pass through the two centres (white and
black crosses). It appears to mark the symmetry axis for the density
distribution in Tycho SNR. In fact, this property provides strong evidence for
the presence of a large-scale density gradient in the ISM around Tycho’s SNR,
which is directed towards the north-west, along the yellow line. Theoretical
studies demonstrate (Hnatyk & Petruk, 1999) that the actual centre of the SNR
should be shifted with respect to the geometrical one in the direction of the
gradient of the ambient density. Thus, our figure is an independent
confirmation of the explosion center found by Xue & Schaefer (2015).

There is ‘direct’ evidence for a pre-shock density variation around Tycho SNR.
One piece of evidence comes from proper motion analysis of the forward shock
in Tycho’s SNR on the basis of radio observations (Reynoso et al., 1997).
Figure 7 in this reference shows the azimuthal variation of the expansion
parameter $m=(\Delta R/\Delta t)/(R/t)$. As from this study, $m$ marks
prominent shock deceleration – due to the interaction with increased density –
in the north-western direction. This is the same as the direction of the
density gradient we found.

In the same study, the parameter $m$ also demonstrates a strong shock
deceleration towards the east, along the azimuth $\approx 70^{\mathrm{o}}$
(counterclockwise from the north). A considerable decrease of the expansion
velocity at this azimuth is confirmed by X-ray data as well (Williams et al.,
2016). Analysis of infrared observations reveals a prominent increase of the
pre-shock density in both the north-western and eastern directions (Williams
et al., 2013).

In contrast, our map on Fig. 1 does not reflect a density enhancement towards
the east. Our method does not ‘measure’ the density around the shock. It
instead relies on the internal distributions. Therefore, the difference
between the two azimuths should be due to different spatial scales of the
corresponding over-densities and time-scales of interactions. The one towards
the north-west is large-scale (larger than the SNR radius). Therefore, the SNR
evolved throughout its entire life in an ISM with this gradient, and the
internal structure of the SNR has has enough time to adapt to such an ambient
density variation. In contrast, the density enhancement on the east should be
localized, and the interaction with the shock is small-scale. According to our
interpretation, the shock has encountered it rather recently, so the
downstream structure does not reflect this interaction yet, unlike the shock
itself.

Recent deceleration of the shock at azimuth $\approx 70^{\mathrm{o}}$ is
confirmed by the analysis of the proper motion of the forward shock from
multi-epoch X-ray observations between years 2003 and 2015 (Tanaka et al.,
2021, their region 4). The authors found as well a prominent gradual decrease
of the shock speed for the south and south-western edge of Tycho’s SNR (their
regions 6–10, azimuths $150-270$ degrees). There is a sign of such a behaviour
(namely, smaller $m$) around the azimuth $180^{\mathrm{o}}$ in figure 7 in
Reynoso et al. (1997). Tanaka et al. (2021) interpreted this as evidence of a
recent interaction with a denser cavity wall. However, there is no excessive
post-shock density found in the infrared 2004 data in the south and south-west
(Williams et al., 2013) that could result in such a rapid deceleration. Thus,
in the scenario proposed by Tanaka et al. (2021), the south-west portion of
the shock should start interaction with a higher-density feature in more
recent times than the eastern portion around the azimuth $70^{\mathrm{o}}$
because the over-density at this azimuth is visible in the infrared data.

Fig. 1 right demonstrates that the MF map in Tycho’s SNR has an arch-like
feature. In case of a uniform ambient MF, the MF configuration in the SNR is
expected to be barrel-like due to a higher compression of the tangential MF
component compared to the radial one. The MF projection would then have two
symmetric limbs. Such an arch-like configuration in Tycho’s SNR could appear
if e.g. the two limbs are slanted toward the east and converging there. Such a
configuration (Orlando et al., 2007, 2011) may naturally happen if the
gradient of the ambient MF is directed towards the east and it is just swept-
up and compressed by the shock. Instead, if such a young SNR still has
significant amplification of the MF around the forward shock, then one would
expect that MF upstream is approximately either:

$\delta B^{2}\propto n_{\mathrm{o}}V^{3},$ (12)

for non-resonant amplification, or:

$\delta B^{2}\propto B_{\mathrm{o}}n_{\mathrm{o}}^{1/2}V,$ (13)

for the resonant case. The compression of such a disordered MF by the shock is
independent of its obliquity. Thus, in the first case, we expect the MF map to
look similar to the density map, which is not the case for ours, or to be
dominated by the regions with the highest shock speed $V$, which are neither
those on the north-west or east. The resonant amplification case could in
principle result in a MF map as on Fig. 2 if the ordered ambient $B$ dominates
the azimuthal variation of density and shock speed.

The symmetry axis of the MF distribution seems parallel to the white dashed
line running from the west to the east (which indicates Galactic latitude
$b=+1.4\arcdeg$). Therefore, the ISMF gradient around Tycho’s SNR is parallel
to the Galactic plane. Interestingly, such orientation differs from the
orientation of the MF gradient in the remnant SN1006, where it is directed
towards the Galactic plane (Bocchino et al., 2011).

We have no observational clues regarding the orientation of the ambient MF.
The radio and X-ray polarisation maps reveal a mostly radial MF inside the SNR
projection (Reynoso et al., 1997; Ferrazzoli et al., 2023). This is a young
SNR, and the generation of a turbulent MF should be efficient. Such a MF
component can change considerably the MF direction compared to what we may
expect in the case of a simple compression of the interstellar field.

To summarise, it looks like the ambient environment around Tycho’s SNR has the
large-scale gradients: of the density in the north-west direction, and of the
MF, which is oriented toward the east and is almost parallel to the Galactic
plane.

###  4.2 Cut-off frequency and maximum energy of the electrons

The electrons emitting X-rays suffer from radiative losses. They lose energy
rather quickly and the synchrotron X-ray rims of SNRs are therefore thin. We
see this clearly in the distributions of the cut-off frequency and the maximum
energy on Fig. 2. The highest values are around the SNR edge, with a trend to
somewhat larger cut-off frequencies and maximum energies in the western half
of the remnant’s rim.

The azimuth variation of the cut-off frequency around the SNR edge is plotted
on Fig. 4 for angular bins of 3 degrees. One of the most prominent
enhancements is in the region of the recent shock-cloud interaction around
azimuth $70^{\mathrm{o}}$. The local values reach up to
$\nu_{\mathrm{cr}}\simeq 0.42{\,\rm keV}$ and $E_{\mathrm{max}}\simeq 11{\,\rm
TeV}$ at this location. The variation of the cut-off frequency in other
regions is typically within $50\%$ of the mean value for the whole rim, with
evidence for values systematically above the mean in the western part of the
shell (azimuth from $180$ to $290$ degrees, Fig. 4).

Lopez et al. (2015) measured the cut-off frequency by fitting the NuSTAR
spectrum in several regions over the remnant. Their figure 10 shows features
similar to ours: in the interior, $\nu_{\mathrm{cr}}$ is generally smaller by
a factor of $\approx 2.5$ compared to the rim; it is higher over the western
rim and locally in the east. They estimated, by assuming a uniform MF, that
$E_{\mathrm{max}}$ varies spatially in the range of $5-12{\,\rm TeV}$. Parizot
et al. (2006) estimated a MF strength of $B\approx 200{\,\rm\mu G}$ from rim
thickness as well as a maximum energy of electrons $E_{\mathrm{max}}\simeq
5-7{\,\rm TeV}$. These numbers agree with our calculations (Fig. 2, bottom).

On both our maps (for $\nu_{\mathrm{cr}}$ and $E_{\mathrm{max}}$, Fig. 2), we
see higher values also around well-known non-thermal features such as the
stripes at the west ($E_{\mathrm{max}}\simeq 4.0{\,\rm TeV}$) and the arch in
the south-east region ($E_{\mathrm{max}}\simeq 3.7{\,\rm TeV}$) that prove
efficient energization of particles there. The overall distribution of the
maximum energy on our image is characterized by a mean
$E_{\mathrm{max}}=2.6{\,\rm TeV}$ and a standard deviation $0.9{\,\rm TeV}$.
It is $E_{\mathrm{max}}=4.0\pm 1.7{\,\rm TeV}$ for the rim.

Figure 4: Mean and standard deviation of $\nu_{\mathrm{cr}}$ around the SNR
edge. The azimuth is measured counterclockwise from the north. Each point on
the plot is calculated with the data from a region limited by a $3$-degrees
sector and $5\%$ extension inward along a radius from the edge. The black
horizontal line shows the mean value for the whole rim (within $5\%$ of the
radius).

###  4.3 On the gamma-ray emission

Tycho’s SNR was detected in GeV (Giordano et al., 2012) and TeV (Acciari et
al., 2011) $\gamma$-rays. Hadronic $\gamma$-rays arise from regions with a
high density of target protons. There are two preferable locations in the case
of Tycho’s SNR, where the shock is interacting with denser ISM (Williams et
al., 2013): in the north-west (in the direction of the large-scale gradient)
and in the east (around azimuth $70^{\mathrm{o}}$).

Neither VERITAS nor Fermi can resolve the object to distinguish between the
two locations. Indeed, the centroid position for the TeV $\gamma$-ray emission
is in the middle of the line between the two sites (Acciari et al., 2011,
their figure 1). In the GeV $\gamma$-rays, the centroid is around the center
of SNR (Giordano et al., 2012; Archambault et al., 2017), i.e. is also between
the two sites.

Our results could shed some light on differences in particle acceleration and
$\gamma$-ray emission at these two locations. The shock speed $V$ in the
north-west is around $3400{\,\rm km/s}$ and near $2000{\,\rm km/s}$ in the
east (Williams et al., 2013). One would expect to have more efficient
acceleration of cosmic rays in the north-west because of the higher shock
speed. However, it follows from our results that $V$ measured in the east got
smaller recently and sharply, in contrast to the north-west where the shock
was decelerating continuously from early times due to increasing ambient
density. Before the encounter with the dense material in the east, the shock
speed could be as high as the highest $V$ in Tycho (which is around
$4000{\,\rm km/s}$; the same reference). The fact that $E_{\mathrm{max}}$ for
the electrons is higher in the east (being achieved before the sharp decrease
of the shock speed due to a recent interaction with an over-density) than in
the north-west (where the shock speed was lower for a long time) confirms such
a scenario (Fig. 2 bottom). Thus, we would favour the eastern region as the
major site contributing to the $\gamma$-ray flux: cosmic rays were accelerated
efficiently at the fast shock there and then ‘suddenly’ hit the cloud with a
high density of target protons. This supports the scenario of particle
acceleration in a shock interacting with dense medium described by Morlino &
Blasi (2016).

We are thankful to Adam Foster for valuable suggestions related to usage of
the AtomDB data in numerical calculations as well as to Riccardo Ferrazzoli
who provided us with the synchrotron fraction map for Tycho SNR. This paper
employs a list of Chandra datasets, obtained by the Chandra X-ray Observatory,
contained in https://doi.org/10.25574/cdc.259 (catalog DOI: 10.25574/cdc.259).
O.P. acknowledges the OAPa grant number D.D.75/2022 funded by Direzione
Scientifica of Istituto Nazionale di Astrofisica, Italy. L.C. is grateful for
support from National Science Foundation grants AST-2107070 and AST-2205628.
This project has received funding through the MSCA4Ukraine project, which is
funded by the European Union. Views and opinions expressed are however those
of the authors only and do not necessarily reflect those of the European
Union. Neither the European Union nor the MSCA4Ukraine Consortium as a whole
nor any individual member institutions of the MSCA4Ukraine Consortium can be
held responsible for them. The National Radio Astronomy Observatory is a
facility of the National Science Foundation operated under cooperative
agreement by Associated Universities, Inc. This work made use of the HPC
system MEUSA, part of the Sistema Computazionale per l’Astrofisica Numerica
(SCAN) of INAF-Osservatorio Astronomico di Palermo, Italy.

##  Appendix A Cooling function in the photon energy range 1.2-4.0 keV

In order to get rid of the dependence of the cooling function $\Lambda$ on the
temperature and ionization state of the plasma, we adopt the photon energy
range 1.2-4 keV. Fig. 5 left shows $\Lambda(T)$ for CIE as well as for NEI for
a few values of the ionization parameter $\tau\equiv n_{\mathrm{o}}t$. In
order to calculate the plot, we have used the `PyAtomDB` code
(https://pypi.org/project/pyatomdb/) with the abundance, which is the default
in `XSPEC`. It is evident that $\Lambda(T)\approx\mathrm{const}$ for
$T>10^{7}{\,\rm K}$ as in the CIE as in the NEI conditions. The maximum
possible differences in $\Lambda$ due to local conditions are less than factor
2 (green and red lines on the figure). For reference, typical values of $\tau$
in Tycho SNR are $\tau\sim 2\times 10^{8}{\,\rm cm^{-3}s}$ for thin regions of
swept-up ISM around the forward shock and $\tau\sim 0.3-1\times 10^{11}{\,\rm
cm^{-3}s}$ in the ejecta behind (Decourchelle et al., 2001; Hwang et al.,
2002; Ellien et al., 2023).

What could be an effect of spatial variation of abundance? The lines from Si
and S are most prominent in the X-ray spectrum of Tycho SNR in the photon
energies 1.2-4 keV. These two elements almost coincide spatially. Based on
_XMM-Newton_ observations of the remnant, Miceli et al. (2015) derived the
equivalent width map for Si which is a good proxy for its abundance (Fig. 5
right). This map demonstrates that variation of Si abundance is at most to the
factor of two over the remnant. This is the same level of uncertainty as due
to $\tau$.

Figure 5: Left. The dependence $\Lambda(T)$ in the photons with energy
$1.2-4.0{\,\rm keV}$. CIE (blue line) and NEI with values of $\tau$ shown in
the legend. The line for $\tau=5\times 10^{12}{\,\rm cm^{-3}s}$ almost
coincides with the CIE line. Right. Equivalent width map for the Si emission
lines in the $1.65–2.05$ keV band. The color scale is in keV. The contours
correspond to the map in $4.4-6.1$ keV and are plotted at the levels $10\%$
and $30\%$ of the maximum.

## References

  * Acciari et al. (2011) Acciari, V. A., Aliu, E., Arlen, T., et al. 2011, ApJ, 730, L20, doi: 10.1088/2041-8205/730/2/L20
  * Archambault et al. (2017) Archambault, S., Archer, A., Benbow, W., et al. 2017, ApJ, 836, 23, doi: 10.3847/1538-4357/836/1/23
  * Arias et al. (2019) Arias, M., Vink, J., Zhou, P., et al. 2019, AJ, 158, 253, doi: 10.3847/1538-3881/ab4f80
  * Bocchino et al. (2011) Bocchino, F., Orlando, S., Miceli, M., & Petruk, O. 2011, A&A, 531, A129, doi: 10.1051/0004-6361/201016341
  * Cai et al. (2009) Cai, Z.-Y., Yang, J., & Lu, D.-R. 2009, Chinese Astron. Astrophys., 33, 393, doi: 10.1016/j.chinastron.2009.09.005
  * Cassam-Chenaï et al. (2007) Cassam-Chenaï, G., Hughes, J. P., Ballet, J., & Decourchelle, A. 2007, ApJ, 665, 315, doi: 10.1086/518782
  * Chen et al. (2017) Chen, X., Xiong, F., & Yang, J. 2017, A&A, 604, A13, doi: 10.1051/0004-6361/201630003
  * Chiotellis et al. (2013) Chiotellis, A., Kosenko, D., Schure, K. M., Vink, J., & Kaastra, J. S. 2013, MNRAS, 435, 1659, doi: 10.1093/mnras/stt1406
  * Decourchelle et al. (2001) Decourchelle, A., Sauvageot, J. L., Audard, M., et al. 2001, A&A, 365, L218, doi: 10.1051/0004-6361:20000115
  * Ellien et al. (2023) Ellien, A., Greco, E., & Vink, J. 2023, ApJ, 951, 103, doi: 10.3847/1538-4357/accc85
  * Fang et al. (2018) Fang, J., Yu, H., & Zhang, L. 2018, MNRAS, 474, 2544, doi: 10.1093/mnras/stx2921
  * Ferrand et al. (2019) Ferrand, G., Warren, D. C., Ono, M., et al. 2019, ApJ, 877, 136, doi: 10.3847/1538-4357/ab1a3d
  * Ferrazzoli et al. (2023) Ferrazzoli, R., Slane, P., Prokhorov, D., et al. 2023, ApJ, 945, 52, doi: 10.3847/1538-4357/acb496
  * Giordano et al. (2012) Giordano, F., Naumann-Godo, M., Ballet, J., et al. 2012, ApJ, 744, L2, doi: 10.1088/2041-8205/744/1/L2
  * Godinaud et al. (2023) Godinaud, L., Acero, F., Decourchelle, A., & Ballet, J. 2023, A&A, 680, A80, doi: 10.1051/0004-6361/202346954
  * Hayato et al. (2010) Hayato, A., Yamaguchi, H., Tamagawa, T., et al. 2010, ApJ, 725, 894, doi: 10.1088/0004-637X/725/1/894
  * Hnatyk & Petruk (1999) Hnatyk, B., & Petruk, O. 1999, A&A, 344, 295.  https://arxiv.org/abs/astro-ph/9901229
  * Hwang et al. (2002) Hwang, U., Decourchelle, A., Holt, S. S., & Petre, R. 2002, ApJ, 581, 1101, doi: 10.1086/344366
  * Ishihara et al. (2010) Ishihara, D., Kaneda, H., Furuzawa, A., et al. 2010, A&A, 521, L61, doi: 10.1051/0004-6361/201015131
  * Katsuda et al. (2010) Katsuda, S., Petre, R., Hughes, J. P., et al. 2010, ApJ, 709, 1387, doi: 10.1088/0004-637X/709/2/1387
  * Katz-Stone et al. (2000) Katz-Stone, D. M., Kassim, N. E., Lazio, T. J. W., & O’Donnell, R. 2000, ApJ, 529, 453, doi: 10.1086/308251
  * Kobashi et al. (2024) Kobashi, R., Lee, S.-H., Tanaka, T., & Maeda, K. 2024, ApJ, 961, 32, doi: 10.3847/1538-4357/ad05c2
  * Krause et al. (2008) Krause, O., Tanaka, M., Usuda, T., et al. 2008, Nature, 456, 617, doi: 10.1038/nature07608
  * Lee et al. (2004) Lee, J.-J., Koo, B.-C., & Tatematsu, K. 2004, ApJ, 605, L113, doi: 10.1086/420869
  * Lopez et al. (2015) Lopez, L. A., Grefenstette, B. W., Reynolds, S. P., et al. 2015, ApJ, 814, 132, doi: 10.1088/0004-637X/814/2/132
  * Miceli et al. (2015) Miceli, M., Sciortino, S., Troja, E., & Orlando, S. 2015, ApJ, 805, 120, doi: 10.1088/0004-637X/805/2/120
  * Millard et al. (2022) Millard, M. J., Park, S., Sato, T., et al. 2022, ApJ, 937, 121, doi: 10.3847/1538-4357/ac8f30
  * Moranchel-Basurto et al. (2020) Moranchel-Basurto, A., Velázquez, P. F., Ares de Parga, G., et al. 2020, MNRAS, 494, 1531, doi: 10.1093/mnras/staa627
  * Morlino & Blasi (2016) Morlino, G., & Blasi, P. 2016, A&A, 589, A7, doi: 10.1051/0004-6361/201527761
  * Morlino & Caprioli (2012) Morlino, G., & Caprioli, D. 2012, A&A, 538, A81, doi: 10.1051/0004-6361/201117855
  * Orlando et al. (2008) Orlando, S., Bocchino, F., Reale, F., Peres, G., & Pagano, P. 2008, ApJ, 678, 274, doi: 10.1086/529420
  * Orlando et al. (2007) Orlando, S., Bocchino, F., Reale, F., Peres, G., & Petruk, O. 2007, A&A, 470, 927, doi: 10.1051/0004-6361:20066045
  * Orlando et al. (2011) Orlando, S., Petruk, O., Bocchino, F., & Miceli, M. 2011, A&A, 526, A129, doi: 10.1051/0004-6361/201015505
  * Parizot et al. (2006) Parizot, E., Marcowith, A., Ballet, J., & Gallant, Y. A. 2006, A&A, 453, 387, doi: 10.1051/0004-6361:20064985
  * Petruk et al. (2009) Petruk, O., Bocchino, F., Miceli, M., et al. 2009, MNRAS, 399, 157, doi: 10.1111/j.1365-2966.2009.15352.x
  * Petruk et al. (2021) Petruk, O., Kuzyo, T., Orlando, S., Pohl, M., & Brose, R. 2021, MNRAS, 505, 755, doi: 10.1093/mnras/stab1319
  * Reynolds et al. (2021) Reynolds, S. P., Williams, B. J., Borkowski, K. J., & Long, K. S. 2021, ApJ, 917, 55, doi: 10.3847/1538-4357/ac0ced
  * Reynoso et al. (1997) Reynoso, E. M., Moffett, D. A., Goss, W. M., et al. 1997, ApJ, 491, 816, doi: 10.1086/304997
  * Reynoso et al. (1999) Reynoso, E. M., Velázquez, P. F., Dubner, G. M., & Goss, W. M. 1999, AJ, 117, 1827, doi: 10.1086/300814
  * Sato & Hughes (2017) Sato, T., & Hughes, J. P. 2017, ApJ, 840, 112, doi: 10.3847/1538-4357/aa6f60
  * Tanaka et al. (2021) Tanaka, T., Okuno, T., Uchida, H., et al. 2021, ApJ, 906, L3, doi: 10.3847/2041-8213/abd6cf
  * Uchida et al. (2024) Uchida, H., Kasuga, T., Maeda, K., et al. 2024, ApJ, 962, 159, doi: 10.3847/1538-4357/ad1ff3
  * van Haarlem et al. (2013) van Haarlem, M. P., Wise, M. W., Gunst, A. W., et al. 2013, A&A, 556, A2, doi: 10.1051/0004-6361/201220873
  * Vigh et al. (2011) Vigh, C. D., Velázquez, P. F., Gómez, D. O., et al. 2011, ApJ, 727, 32, doi: 10.1088/0004-637X/727/1/32
  * Warren et al. (2005) Warren, J. S., Hughes, J. P., Badenes, C., et al. 2005, ApJ, 634, 376, doi: 10.1086/496941
  * Wilhelm et al. (2020) Wilhelm, A., Telezhinsky, I., Dwarkadas, V. V., & Pohl, M. 2020, A&A, 639, A124, doi: 10.1051/0004-6361/201936079
  * Williams et al. (2013) Williams, B. J., Borkowski, K. J., Ghavamian, P., et al. 2013, ApJ, 770, 129, doi: 10.1088/0004-637X/770/2/129
  * Williams et al. (2016) Williams, B. J., Chomiuk, L., Hewitt, J. W., et al. 2016, ApJ, 823, L32, doi: 10.3847/2041-8205/823/2/L32
  * Williams et al. (2017) Williams, B. J., Coyle, N. M., Yamaguchi, H., et al. 2017, ApJ, 842, 28, doi: 10.3847/1538-4357/aa7384
  * Xu et al. (2011) Xu, J.-L., Wang, J.-J., & Miller, M. 2011, Research in Astronomy and Astrophysics, 11, 537, doi: 10.1088/1674-4527/11/5/004
  * Xue & Schaefer (2015) Xue, Z., & Schaefer, B. E. 2015, ApJ, 809, 183, doi: 10.1088/0004-637X/809/2/183
  * Zhou et al. (2016) Zhou, P., Chen, Y., Zhang, Z.-Y., et al. 2016, ApJ, 826, 34, doi: 10.3847/0004-637X/826/1/34